Re: Moving bash from essential/required to important?
On Monday 04 April 2011 18.04:20 Luk Claes 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. Do you have any kind of estimate how many peopl would need to depend on bash? If it's a few hundred: no problem, why not tackle this as a wheezy release goal. If it's 4000, don't bother. cheers -- vbi -- featured product: the GNU Compiler Collection - http://gcc.gnu.org signature.asc Description: This is a digitally signed message part.
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
* Josselin Mouette j...@debian.org [110404 14:05]: 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. You mix two things up here: Almost noone demands a system that is only configurable after reading a dozen pages of documentation to get it work. But what many people[1] want is that you can make it work if you read some dozen pages of documentation. It's the elementary freedom to be able to fix it yourself. Having the source and the right to modify the software is one part, but in practise having a system that one can understand in depth and actualy force to do what one want is an important aspect for people to choose Debian. Having a nice automagic opaque interface with three buttons of the kind on, off, repair might look very user-friendly. But as every paternalism it is only nice as long as you want what your superior wants. And many people react very emotional to being the inferior of a computer too stupid to understand anything. Bernhard R. Link [1] especially those that have always been a large group of Debian users -- 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/20110405061554.ga2...@pcpool00.mathematik.uni-freiburg.de
Re: Moving bash from essential/required to important?
Steve Langasek vor...@debian.org writes: 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. :-) So why not provide a system shell and a login shell? Both could be provided by dash or bash (or other shells that proove to be compatible like zsh as login shell). But the system shell would default to dash while the login shell defaults to bash. Both system shell and login shell would be essential but neither dash nor bash needs to be. Like awk being essential but neither mawk nor gawk is. Imediate use cases would be twofold: 1) embedded systems that can suffer through dash as login shell 2) users that want zsh instead of bash as login shell 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. So lets start with saying that things that use bash need to depend on it so we will have the option to make bash not essential in the future. This will take some time to do and a release cycle. Worst case we get a bunch of depends on bash that aren't needed. 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/87pqp1nrgf.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
Lars Wirzenius l...@liw.fi writes: * 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. I've beend thinking about this a while back when I had a package fail due to missing Depends for some shell script. So I would even take it a step further. dpkg-shlibsdebs finds all depends needed for dynamic libraries automatically. Why not find all depends needed for shell scripts automatically too? 1) check shebang for the needed shell 2) parse shell script and extract all executables being called 3) lookup packages for for binaries 4) remove essential packages 5) set substvar So if you have a script like #!/usr/bin/zsh if [ grep-dctrl foo bar ]; then echo buzz fi you would get a dependency on zsh and dctrl-tools. 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/87lizpnr3v.fsf@frosties.localnet
Re: Moving bash from essential/required to important?
Luk Claes l...@debian.org writes: 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?)? Then a fsck failure won't give you a shell because you can't input the root password. 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/87hbadnr0i.fsf@frosties.localnet
Re: Back to technical discussion? Yes!
On 05 Apr 00:55, Stanislav Maslovski wrote: 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. It is?! I better tell my /etc/network/interfaces that those wpa keys in there shouldn't work... (I use ifupdown on my laptop *lots*, it has *several* wireless configurations in /etc/network/interfaces, and a magical mapping script that uses iwlist scan to check where we are... it all just works including the WPA configuration...) -- Brett Parker http://www.sommitrealweird.co.uk/ PGP Fingerprint 1A9E C066 EDEE 6746 36CB BD7F 479E C24F 95C7 1D61 -- 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/20110405060819.gc3...@sommitrealweird.co.uk
Re: System users: removing them
]] Lars Wirzenius Hi, | 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. I think never deleting is the most sensible solution, the reasoning being: - UIDs are a cheap resource (we can use 32 bit uids nowadays), the overhead in /etc/passwd and friends is neglible. - Most or all system accounts are locked and unable to be used for login. Perhaps policy should say that user accounts belonging to a package must be locked when the package is removed? - The possible downside of reusing a UID is real. - Giving the admin a way to set policy to delete users means we have more code paths to test, meaning the likehood of bugs popping up increases. The same argument applies for system gids and groups, btw. Regards, -- 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/87hbad2ogg@qurzaw.varnish-software.com
Re: Moving bash from essential/required to important?
Carsten Hey cars...@debian.org writes: 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: * 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. I have no problem with bash being build-essential to avoid needing Build-Depends: bash. This is really a seperate issue from bash being essential. 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/87d3l1nqrz.fsf@frosties.localnet
Re: System users: removing them
Tollef Fog Heen tfh...@err.no writes: - Most or all system accounts are locked and unable to be used for login. Perhaps policy should say that user accounts belonging to a package must be locked when the package is removed? Speaking of that, fixing Bug#274229 and the merged bugs for wheezy would sure be nice. -- 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/8762qtdwdq@windlord.stanford.edu
Bug#620939: ITP: crafty-bitmaps -- bitmap images for crafty chess game annotation mode
Package: wnpp Severity: wishlist Owner: Oliver Korff o...@xynyx.de * Package name: crafty-bitmaps Version : 1.0 Upstream Author : George Barrett grbar...@eecs.umich.edu * URL : ftp://ftp.cis.uab.edu/pub/hyatt/book/bitmaps.tgz * License : GPL-2.0+ Programming Lang: None Description : bitmap images for crafty chess game annotation mode crafty is able to annotate PGN (Portable Game Notation) format chess games. This annotaion mode produces output in HTML-format and needs graphics to be user viewable. This package provides these graphics. -- 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/20110405064638.5065.91164.report...@r2d2.linuxchess.lan
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 07:08:19AM +0100, Brett Parker wrote: On 05 Apr 00:55, Stanislav Maslovski wrote: 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. It is?! I better tell my /etc/network/interfaces that those wpa keys in there shouldn't work... Well, I guess you did not read the text you replied to. That was about the problems with Debian installer, not with ifupdown-based setups in general. As you may have noticed, I have been trying to convince people that ifupdown and wpa may work perfectly when properly configured since yesterday. Therefore I believe that the known problems with installer can be actually solved without switching to NM. (I use ifupdown on my laptop *lots*, it has *several* wireless configurations in /etc/network/interfaces, and a magical mapping script that uses iwlist scan to check where we are... it all just works including the WPA configuration...) So do I, and it just works. -- 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/20110405065935.GA3684@kaiba.homelan
Re: Back to technical discussion? Yes!
]] Stanislav Maslovski | 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. d-i doesn't use ifupdown, it uses netcfg. -- 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/878vvp2mx4@qurzaw.varnish-software.com
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
In other news for Tue, Apr 05, 2011 at 08:15:55AM +0200, Bernhard R. Link has been seen typing: But what many people[1] want is that you can make it work if you read some dozen pages of documentation. Personally, what I want is a setup that does not drop all active network interfaces during a software upgrade because it needs to restart a daemon. Making network-manager honor an option along the lines of --leave-interfaces during stop or restart would be a good start. -- 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/20110405070633.ge9...@proteus.systemec.nl
Re: MBF: Getting rid of unneeded *.la / emptying dependency_libs
On Mon, 4 Apr 2011 16:12:42 -0700 Steve Langasek vor...@debian.org wrote: 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. I'm trying to avoid those build failures, hence not asking for changes in packages which still have dependencies which will look for the dependency_libs data at build-time. Those packages only get bugs filed when those dependencies have been fixed to either clear dependency_libs or remove the .la file. e.g. once I fix gpe-expenses to not contain the .la in libqofexpensesobjects-dev, then qof can be fixed to not include the .la file in libqof-dev because libpilotobjects-dev has already been fixed and so it goes on. The nice thing about this MBF is that it can all be done within the Debian revisions of the packages concerned. There are no upstream requirements here, no changes in debian/patches, so every bug is potentially fixable with a trivial NMU - as long as the sequence is followed, we shouldn't see any increase in FTBFS bugs due to this MBF. 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. Exactly. I'm still not sure if it's worth retaining the .a if the .la is removed. I think for high-end libraries like GUIs or any library which depends on a long list of other libraries, the likelihood of anyone needing a static linkage of the entire stack is infinitesimal. I am thinking that libts-dev should retain the .a but I'm open to comments to the contrary. Currently, I'm thinking of simply removing the .la file from libts-dev. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgphynFCME69t.pgp Description: PGP signature
Bug#620943: ITP: evtest -- utility to monitor input device events
Package: wnpp Severity: wishlist Owner: Stephen Kitt st...@sk2.org * Package name: evtest Version : 1.27 Upstream Author : Peter Hutterer peter.hutte...@redhat.com * URL : http://cgit.freedesktop.org/evtest/ * License : GPLv2 Programming Lang: C Description : utility to monitor input device events evtest monitors an input device, displaying all the events it generates. . It can be used to determine mice button bindings, keymaps for exotic keyboards... It is commonly used to debug issues with input devices in X.Org. evtest used to be part of joystick (linuxconsole), but is now maintained separately. I therefore intend to remove evtest from the joystick package (which I maintain) and introduce a separate source package for evtest. Regards, Stephen -- 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/20110405074113.3641.10952.report...@heffalump.sk2.org
Re: Moving bash from essential/required to important?
On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh rle...@codelibre.net wrote: 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.] I really really disagree... In case of disaster running under root is essential. Bastien -- 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/banlktik_bddvqqrkz8ke_8mh_tcus_+...@mail.gmail.com
Re: Moving bash from essential/required to important?
On ma, 2011-04-04 at 20:32 +0100, Lars Wirzenius wrote: 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. I made some changes to the scripts to the scripts: * unpack-debian-binaries now handles multiple binary packages from he same source package; previously it would use only the data.tar.* from one of the binary packages, and this is why gzip's scripts in /bin didn't show up (thanks Carsten) * isbash now looks for a hashbang that includes bash at all, which should cover things like #!/usr/bin/env bash and #!/bin/bash -e (raised in IRC) * find-bash-scripts now also searches through the contents of control.tar.* (thanks, Luk) New versions of the scripts attached. I'm re-running the scripts, which will probably take a few hours, and will report results when they're done. If you notice any problems with the scripts, please tell me ASAP. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ find-bash-scripts Description: application/shellscript isbash Description: application/shellscript unpack-debian-binaries Description: application/shellscript
Re: network-manager as default? No!
Jon Dowland wrote: 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. True. ifupdown doesn't do those either by default; the argument was that it's *extendable* enough to be able to do these via simple addon hooks. Regards, Faidon -- 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/4d9ac81f.90...@debian.org
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 09:10:47AM +0200, Tollef Fog Heen wrote: ]] Stanislav Maslovski | 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. d-i doesn't use ifupdown, it uses netcfg. Hm, okay, I was pretty sure J.M. at some point mentioned replacing ifupdown _in the installer_ with network manager… Then, the current limitations of the installer are not even related to ifupdown at all. That is a good news. -- 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/20110405080942.GA6830@kaiba.homelan
Re: dh_shlibdeps warnings concerning undefined OpenMP symbols
On 31.03.2011 22:16, Jakub Wilk wrote:
You do need -lgomp.
You normally don't (need to) link to gomp explicitly. My wild guess is:
Dmitry used -fopenmp while compiling *.o, but not when linking the
shared library.
Exactly! Thank you, Jakub, for nice guess.
AC_OPENMP() macro documentation looks to be a bit incomplete (e.g. if it
provides $OPENMP_LDFLAGS I wouldn't mess things), so I believe the
correct sequence looks like this:
AC_OPENMP()
CPPFLAGS=${OPENMP_CFLAGS} ${CPPFLAGS}
CXXFLAGS=${OPENMP_CXXFLAGS} ${CXXFLAGS}
LDFLAGS=${OPENMP_CXXFLAGS} ${LDFLAGS}
On 01.04.2011 14:47, Jakub Wilk wrote:
I don't think there's anything wrong with this macro. CXXFLAGS should be
used both for compiling and linking. At least this is what GNU make do
by default:
$ make -p 2/dev/null | grep 'LINK.cc = '
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
Thank you! It looks like I need to use $(LINK.cc) to link the .so library.
I also was suggested this resource:
http://wiki.debian.org/ToolChain/DSOLinking#Unresolved_symbols_in_shared_libraries
which explains that this warning is raised, when the dependency chain is
like A - B - C, and A needs symbols from C, but has no direct
dependency A - C (which should be introduced as Brian also mentioned).
Thanks a lot for help to everyone!
--
With best regards,
Dmitry
--
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/4d9acf08.4010...@mail.ru
Re: Back to technical discussion? Yes!
On Tue, Apr 05, 2011 at 12:09:42PM +0400, Stanislav Maslovski wrote: On Tue, Apr 05, 2011 at 09:10:47AM +0200, Tollef Fog Heen wrote: ]] Stanislav Maslovski | 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. d-i doesn't use ifupdown, it uses netcfg. Hm, okay, I was pretty sure J.M. at some point mentioned replacing ifupdown _in the installer_ with network manager… Then, the current limitations of the installer are not even related to ifupdown at all. That is a good news. Yes, he did. Here: 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 -- 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/20110405082156.GA7988@kaiba.homelan
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 09:36:14AM +0200, Bastien ROUCARIES wrote: On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh rle...@codelibre.net wrote: 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.] I really really disagree... In case of disaster running under root is essential. Of course. This change would in no way prevent running under root in case of problems. If the root account is locked and has no password, you get dropped into a root shell on the console like normal, but the password prompt is skipped, if fatal errors are encountered at startup. 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: Moving bash from essential/required to important?
Goswin von Brederlow goswin-...@web.de writes: Lars Wirzenius l...@liw.fi writes: * 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. I've beend thinking about this a while back when I had a package fail due to missing Depends for some shell script. So I would even take it a step further. dpkg-shlibsdebs finds all depends needed for dynamic libraries automatically. That information is quite neatly and unambigously encoded in the binaries, making extraction of the information both (relatively) easy and reliable. With shell scripts, this is not the case, see below. Why not find all depends needed for shell scripts automatically too? 1) check shebang for the needed shell Seems like a reasonable thing to do. 2) parse shell script and extract all executables being called You can't generally do that without executing the shell script, and even then you'd miss out on stuff that's not invoked due to conditionals. It's certainly possible to get a subset of executables used by parsing, but it's bound to be an unreliable heuristic. Additionally, adding a shell script parser would probably add quite a bunch of code. I don't see the point of doing that when you'd have to check the result anyway, since the information is unreliable -- and when you need to do that, you might as well specify the dependencies manually. 3) lookup packages for for binaries 4) remove essential packages 5) set substvar So if you have a script like #!/usr/bin/zsh if [ grep-dctrl foo bar ]; then echo buzz fi you would get a dependency on zsh and dctrl-tools. One more point: you'd have to write a parser to understand zsh syntax to do that in general. Regards, Rotty -- Andreas Rottmann -- http://rotty.yi.org/ -- 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/87hbadyt3j@gmx.at
Re: Moving bash from essential/required to important?
* Guillem Jover [2011-04-05 06:19 +0200]: On Tue, 2011-04-05 at 01:08:19 +0100, Ben Hutchings wrote: 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? Ah good catch! Done with the attached patch. mksh.prerm contains: remove|upgrade|deconfigure) update-alternatives --remove ksh /bin/mksh update-alternatives --remove ksh /bin/mksh-static remove-shell /bin/mksh remove-shell /bin/mksh-static bash.postrm contains: remove|purge|disappear) if which remove-shell /dev/null [ -f /etc/shells ]; then remove-shell /bin/bash remove-shell /bin/rbash fi ... so they are missing from /etc/shells after they have been removed. Alternatives include a hardcoded list instead of relying on /etc/shells or an additional file that contains all shells that were ever part of /etc/shells. prerm could also fail it the shell is set as root's (or any, otherwise setups using sudo instead of root might break) login shell. 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/20110405090235.gb10...@furrball.stateful.de
Re: Bits from the Release Team - Kicking off Wheezy
Ben Hutchings b...@decadent.org.uk writes: On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote: Josselin Mouette j...@debian.org writes: Le jeudi 31 mars 2011 à 09:25 +0200, Vincent Danjean a écrit : Martin F. Krafft started to implement a replacement of ifupdown that is better designed. But, due to lack of manpower I think, this project did not finish. See this archives of netconf-de...@lists.alioth.debian.org for more info. I wonder what amount of features we are missing for network-manager to do the job; instead of rewriting a daemon from scratch, A daemon will never be able to replace ifupdown. ifupdown will never work correctly. Point taken. Sorry about the noise. udevd has demonstrated that it is possible for a daemon to manage and police all devices in a system, while still keeping the kernel as master of state. You can actually restart udevd without having all you disk devices removed and readded. Of course. So a daemon could do the job. NM, however, can not. I believe the problems with NM is best described by it's current list of bugs, and in particular by the maintainer responses to bugs like #415196. NM can probably be used for really simple desktop setups, but it is not suitable for any non-desktop setup or any non-trivial networking. Bjørn -- 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/87ei5hgj0s@nemi.mork.no
Re: Moving bash from essential/required to important?
On 05/04/11 04:52, Russ Allbery wrote: dash doesn't support $LINENO, which is why it's not detected by Autoconf. The reason why it doesn't support $LINENO (it's intentional; we had a patch to add it that was then removed) is that the configure.ac files of many, many packages contain bashisms that dash doesn't support. If $LINENO support is present in dash, Autoconf considers dash sufficiently POSIX to use as the configure shell, and then all those packages FTBFS. We could do as with binutils-gold. Report bugs with severity important now, make it a release goal to make dash fully POSIX-compliant (including $LINENO support), and if the bug count gets low enough in time, do the switch, and otherwise, do it at the beginning of the next cycle (assuming we've fixed enough bugs). Cheers, Emilio -- 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/4d9ad900.9010...@debian.org
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote: Specifically, the plan is that any package in wheezy shipping a runtime library in a multiarch directory should declare a Pre-Depends on the metapackage 'multiarch-support'. And the dependency would be added by either dpkg-dev, debhelper, or dpkg-shlibdeps rather than being added to every single library by hand, right? -- 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/20110405091254.ga2...@angband.pl
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, 05 Apr 2011 at 11:12:54 +0200, Adam Borowski wrote:
On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
Specifically, the plan is that any package in wheezy shipping a runtime
library in a multiarch directory should declare a Pre-Depends on the
metapackage 'multiarch-support'.
And the dependency would be added by either dpkg-dev, debhelper, or
dpkg-shlibdeps rather than being added to every single library by hand,
right?
Because debhelper doesn't add any Pre-Depends yet, there's nowhere to put
the new dependency that would automatically be picked up. I believe the
current plan is that:
* debhelper adds multiarch-support to a new
${misc:Pre-Depends} substvar (which must be added to the library by hand)
* this is only relevant to packages that divert files into multiarch
directories, which would only happen with package-specific changes anyway
(bumping the debhelper compat level to 9, if nothing else)
* lintian should warn (error?) if a binary package has libraries in a multiarch
directory and doesn't pre-depend on multiarch-support
* lintian should perhaps also warn if a package uses debhelper compat 9
and doesn't pre-depend on ${misc:Pre-Depends}
Regards,
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/20110405101229.ga19...@reptile.pseudorandom.co.uk
Re: Moving bash from essential/required to important?
* Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: 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. This doesn't appear to be relevant to moving bash out of Essential. dash, which would still be Essential (no one is proposing removing /bin/sh from Essential!), also has printf as a shell builtin. It would be good to resolve this bug in its own right, but it appears to be orthogonal to whether bash is Essential. This is only relevant because the next point is in my opinion relevant and fixing the next one might lead the next best maintainer of a policy complying shell to enable this shell to become /bin/sh. If there is no correctly documented consensus (in the policy) about what a shell needs to provide to let scripts rely on printf (and theoretically also [ and test) being available, this could lead to non-bootable systems. * 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. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. We are using different hacks to manage /bin/sh since about five years. Making things even more hackish or complicated, e.g. by not being able to rely on dash or bash to be installed and/or moving /bin/sh around, would increase the number of corner cases to be caught and thus make implementing a clean solution even more hard. 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/20110405101233.gc10...@furrball.stateful.de
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, 5 Apr 2011 11:12:29 +0100
Simon McVittie s...@debian.org wrote:
* lintian should warn (error?) if a binary package has libraries in a
multiarch
directory and doesn't pre-depend on multiarch-support
* lintian should perhaps also warn if a package uses debhelper compat 9
and doesn't pre-depend on ${misc:Pre-Depends}
Instead:
Lintian error (and an ftpmaster REJECT) if debhelper compat 9 is set
with no ${misc:PreDepends} set because that prevents the
multiarch-support addition. A failure to convert ${misc:PreDepends} to
multiarch-support would be a debhelper bug and seems quite unlikely -
but worth checking at ftpmaster level, possibly.
Lintian error (and an ftpmaster REJECT) if a binary package (not just
a library) has multiarch paths without debhelper compat 9. (This
protects against uploading packages converted with tools like
dpkg-cross -M -A (= 2.6.3).)
That way, if multiarch-support is no longer needed as a Pre-Depends, the
lintian error is still correct (but can be downgraded with only a
change in lintian) and the rest of the archive packages need no further
changes. The next package rebuild after we decide that
multiarch-support becomes a no-op and ${misc:PreDepends} goes back to
being the empty string automatically, via a change in debhelper.
That leaves everything in the hands of the debhelper tool to add or
not add the actual Pre-Depends and in the hands of lintian to
check correct deployment, without needing any further package changes
across the archive.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpJQqZDBbsPY.pgp
Description: PGP signature
Re: Flaming as a way to reach technical quality? No!
Steve Langasek vor...@debian.org writes:
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 not going to argue against using network manager for that particular
use case. It does provide a nice GUI for entering credentials etc.
But I will claim that using ifupdown is also easy, given that you can
accept a CLI instead of a GUI:
You need to
1) create a /etc/wpa_supplicant/wpa_supplicant.conf with something like
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
## uncomment this entry to automatically connect to any open network
#network={
# ssid=
# key_mgmt=NONE
#}
2) add this (possibly with another device name) to /etc/network/interfaces:
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp
3) run wpa_cli in a terminal as a user in the netdev group
Adding new networks and other management tasks can easily be done in the
wpa_cli shell. IMHO easier than using NM, as it won't interfere with
e.g. any temporary address I've configured manually. But this is of
course a highly subjective opinion.
Bjørn
--
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/87aag5geyj@nemi.mork.no
Re: Bug#620808: ITP: payyans -- A python utility to convert between ASCII and Unicode.
On Tue, 2011-04-05 at 09:41 +0800, Paul Wise wrote: On Mon, Apr 4, 2011 at 11:03 PM, Ben Hutchings b...@decadent.org.uk wrote: And we already have the 'iconv' and 'recode' commands to do conversion between arbitrary character encodings. These are not character encodings, but specific fonts. See the khmerconverter ITP for some earlier discussion on this: http://bugs.debian.org/31#33 I was thinking that these are ad hoc character encodings defined on the basis of specific fonts. (Like Dingbats, for example.) However, encoding in LTR order even through the script is read RTL really does seem to make these graphical representations rather than character encodings. 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: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, 2011-04-05 at 11:25 +0100, Neil Williams wrote: [...] Lintian error (and an ftpmaster REJECT) if a binary package (not just a library) has multiarch paths without debhelper compat 9. (This protects against uploading packages converted with tools like dpkg-cross -M -A (= 2.6.3).) [...] Do you mean, 'with debhelper, but without debhelper compat 9'? debhelper is of course not mandatory. 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: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, 05 Apr 2011 11:47:01 +0100 Ben Hutchings b...@decadent.org.uk wrote: On Tue, 2011-04-05 at 11:25 +0100, Neil Williams wrote: [...] Lintian error (and an ftpmaster REJECT) if a binary package (not just a library) has multiarch paths without debhelper compat 9. (This protects against uploading packages converted with tools like dpkg-cross -M -A (= 2.6.3).) [...] Do you mean, 'with debhelper, but without debhelper compat 9'? debhelper is of course not mandatory. Yes. Lintian error (and an ftpmaster REJECT) if a binary package (not just a library) has multiarch paths without either debhelper compat 9 or the multiarch-support Pre-Depends. (This protects against uploading packages converted with tools like dpkg-cross -M -A (= 2.6.3).) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpKB1mUVntdz.pgp Description: PGP signature
Bug#620956: ITP: libdata-amf-perl -- Perl module for serialize / deserialize AMF data
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: libdata-amf-perl Version : 0.09-1 Upstream Author : Daisuke Murase types...@cpan.org * URL or Web page : http://search.cpan.org/dist/Data-AMF/ * License : Perl Description : Perl module for serialize / deserialize AMF data This module is (de)serializer for Adobe's AMF (Action Message Format). Data::AMF is core module and it recognize only AMF data, not AMF packet. If you want to read/write AMF Packet, see Data::AMF::Packet instead. -- 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/87zko5j6ys.wl%tak...@asis.media-as.org
Re: Bug#620943: ITP: evtest -- utility to monitor input device events
On Tue, Apr 5, 2011 at 09:41:13 +0200, Stephen Kitt wrote: * Package name: evtest Version : 1.27 Upstream Author : Peter Hutterer peter.hutte...@redhat.com * URL : http://cgit.freedesktop.org/evtest/ * License : GPLv2 Programming Lang: C Description : utility to monitor input device events evtest monitors an input device, displaying all the events it generates. a Linux input device maybe... . It can be used to determine mice button bindings, keymaps for exotic keyboards... It is commonly used to debug issues with input devices in X.Org. Thanks for picking this up! 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/20110405111401.gr3...@radis.liafa.jussieu.fr
Re: Bits from the Release Team - Kicking off Wheezy
Hello, On Mon, 4 Apr 2011 11:56:15 +0100 Ben Hutchings b...@decadent.org.uk wrote: 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'. Well, ifupdown will still need state files, because they are used to store the certain configuration chosen for the given interface during ifup. Another thing is that they may be ignored when the interface isn't really 'up', as per kernel. What do you think? -- WBR, Andrew signature.asc Description: PGP signature
replacement of merkel services in DDPortfolio
Hi, I changed an entry in the ddportfolioservice [1] to reflect the new location to lookup DD assigned debian.net domain names (Paul: thanks for the Wiki edit). There are some more merkel URLs that stopped working. Do you know whether there are replacements on other Debian hosts? The URLs in question are: * all messages (i.e., full text search for developer name on all bug logs) http://merkel.debian.org/~don/cgi/search.cgi?phrase=Jan+Dittberner;search=search * keylog (per-key upload list) (note: uses key fingerprint) http://merkel.debian.org/~enrico/keylog/B2FF1D95CE8F7A22DF4CF09BA73E008FB8DD.html * MIA database information ssh merkel.debian.org /srv/qa.debian.org/mia/mia-query ja...@debian.org * Group membership information ssh merkel.debian.org id jandd [1] http://ddportfolio.debian.net Regards Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/ signature.asc Description: Digital signature
Re: Bits from the Release Team - Kicking off Wheezy
Hello, On Tue, 5 Apr 2011 14:16:30 +0300 Andrew O. Shadoura bugzi...@tut.by wrote: Another thing is that they may be ignored when the interface isn't really 'up', as per kernel. I mean, isn't up when doing ifup, of isn't down when doing ifdown. -- WBR, Andrew signature.asc Description: PGP signature
Re: replacement of merkel services in DDPortfolio
On Tue, Apr 5, 2011 at 13:22:29 +0200, Jan Dittberner wrote: * MIA database information ssh merkel.debian.org /srv/qa.debian.org/mia/mia-query ja...@debian.org s/merkel/qa/ * Group membership information ssh merkel.debian.org id jandd works on any debian.org machine. 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/20110405113409.gs3...@radis.liafa.jussieu.fr
Re: time based freezes
On Mon, Apr 04, 2011 at 12:12:09PM -0400, Scott Kitterman wrote: 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? It would be, but I started it on d-d-a :) Neil -- I think it's your point of view and I don't agree with you here. I have a good relation with the upstream author and don't think it is necessary for me to understand the code. - Request for a freeze exception -- 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/20110404201136.gb46...@feta.halon.org.uk
Re: Back to technical discussion? Yes!
On 04/05/2011 05:21 AM, Stanislav Maslovski wrote: On Tue, Apr 05, 2011 at 12:09:42PM +0400, Stanislav Maslovski wrote: On Tue, Apr 05, 2011 at 09:10:47AM +0200, Tollef Fog Heen wrote: ]] Stanislav Maslovski d-i doesn't use ifupdown, it uses netcfg. Hm, okay, I was pretty sure J.M. at some point mentioned replacing ifupdown _in the installer_ with network manager… Then, the current limitations of the installer are not even related to ifupdown at all. That is a good news. Yes, he did. Here: 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 Splitting hairs. netcfg establishes an initially configured /etc/network/interfaces to make ifupdown work when the user boots into their freshly configured system. I think it's clear enough by context this is what Joss means to change to a purely NM 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/4d9afeb8.1060...@sanctuary.nslug.ns.ca
Re: replacement of merkel services in DDPortfolio
On Tue, 2011-04-05 at 13:22 +0200, Jan Dittberner wrote: I changed an entry in the ddportfolioservice [1] to reflect the new location to lookup DD assigned debian.net domain names (Paul: thanks for the Wiki edit). There are some more merkel URLs that stopped working. Do you know whether there are replacements on other Debian hosts? The URLs in question are: * all messages (i.e., full text search for developer name on all bug logs) http://merkel.debian.org/~don/cgi/search.cgi?phrase=Jan+Dittberner;search=search I thought UDD might be able to do this, but it doesn't have the right options. Maybe Don can comment on where this is moving, CCed. * keylog (per-key upload list) (note: uses key fingerprint) http://merkel.debian.org/~enrico/keylog/B2FF1D95CE8F7A22DF4CF09BA73E008FB8DD.html Code is here: git://git.debian.org/~enrico/keylog.git CCing enrico, hopefully he can give us the status of any replacement. * MIA database information ssh merkel.debian.org /srv/qa.debian.org/mia/mia-query ja...@debian.org * Group membership information ssh merkel.debian.org id jandd These can be replaced with any other Debian machine, I chose master.d.o for the wiki page. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#620957: general: Would you be so kind to include Frandom in the Debian Repositories?
Package: general Severity: wishlist Hello. I would like to see Frandom in the Debian repositories. Frandom is a kernel module for pseudo-random data generation, much as random and urandom, but works incredibly fast. It is currently unmantained. However, is still usefull. You can have a look in http://www.billauer.co.il/frandom.html for more information. -- System Information: Debian Release: 6.0 Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/blu0-smtp60267000ed2bc9516f8350d6...@phx.gbl
Re: replacement of merkel services in DDPortfolio
On 2011-04-05, Julien Cristau jcris...@debian.org wrote: On Tue, Apr 5, 2011 at 13:22:29 +0200, Jan Dittberner wrote: * Group membership information ssh merkel.debian.org id jandd works on any debian.org machine. Only on public/unrestricted hosts. On other hosts you only get a partial list (i.e. those activated on the machines in question). So it's probably mainly master/ravel. Kind regards Philipp Kern -- 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/slrnipm2jh.fd6.tr...@kelgar.0x539.de
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, Apr 05, 2011 at 02:16:30PM +0300, Andrew O. Shadoura wrote: Hello, On Mon, 4 Apr 2011 11:56:15 +0100 Ben Hutchings b...@decadent.org.uk wrote: 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'. Well, ifupdown will still need state files, because they are used to store the certain configuration chosen for the given interface during ifup. Why is that necessary? So far as I can see, the purpose of the state files is: - Let ifup refuse to reapply a configuration (even if it failed to apply it in the first place) - Allow ifdown to take shortcuts, which often don't work They don't even provide the useful feature of copying the configuration that was applied, in case it is subsequently changed or removed in /etc/network/interfaces. Another thing is that they may be ignored when the interface isn't really 'up', as per kernel. What do you think? I don't understand your point. 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/20110405123053.gs2...@decadent.org.uk
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On 2011-04-04 17:31:18 +0400, Stanislav Maslovski wrote: On Mon, Apr 04, 2011 at 05:35:10PM +0530, Josselin Mouette wrote: 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. [About the general problem of documentation] The problem is to find the correct tools and the correct documentation. For instance, imagine the average user who wants for Ethernet (eth0), to do the following automatically (for a laptop): 1. use some fixed IP address if there's some peer 192.168.0.1 with some given MAC address; 2. otherwise, if an Ethernet cable is plugged in (and only in this case), start a DHCP client; 3. make things still work after a suspend/resume. I now know how to do this. But I still wonder what documentation a user should read to achieve such a configuration. It is normal that a user may want to use his laptop from network to network and things work without manual reconfiguration. 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 How does the average user know that he would need to read these pages and not others? (and for most cases just reading that README.Debian should be enough) Yes, the README.Debian seems to give very good information. But users used to man pages may not have the idea to look at this file. I would have thought that users should look at HOWTO's first, but those provided by Debian are obsolete (Networking-Overview-HOWTO is more than 10 years old). 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. The wpa_supplicant(8) man page mentions the CLI (wpa_cli), but not the GUI! So, how would the average user know its existence? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon) -- 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/20110405123140.ga10...@prunille.vinc17.org
Bug#620957: marked as done (general: Would you be so kind to include Frandom in the Debian Repositories?)
Your message dated Tue, 5 Apr 2011 13:32:40 +0100 with message-id 20110405123240.gt2...@decadent.org.uk and subject line Re: Bug#620957: general: Would you be so kind to include Frandom in the Debian Repositories? has caused the Debian Bug report #620957, regarding general: Would you be so kind to include Frandom in the Debian Repositories? to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 620957: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620957 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: general Severity: wishlist Hello. I would like to see Frandom in the Debian repositories. Frandom is a kernel module for pseudo-random data generation, much as random and urandom, but works incredibly fast. It is currently unmantained. However, is still usefull. You can have a look in http://www.billauer.co.il/frandom.html for more information. -- System Information: Debian Release: 6.0 Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- On Tue, Apr 05, 2011 at 01:46:31PM +0200, Ruben wrote: Package: general Severity: wishlist The proper package is 'wnpp'. Hello. I would like to see Frandom in the Debian repositories. Frandom is a kernel module for pseudo-random data generation, much as random and urandom, but works incredibly fast. [...] There is no reason for this to be a kernel module. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus ---End Message---
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On Tue, Apr 05, 2011 at 02:31:40PM +0200, Vincent Lefevre wrote: On 2011-04-04 17:31:18 +0400, Stanislav Maslovski wrote: On Mon, Apr 04, 2011 at 05:35:10PM +0530, Josselin Mouette wrote: 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. [About the general problem of documentation] The problem is to find the correct tools and the correct documentation. For instance, imagine the average user who wants for Ethernet (eth0), to do the following automatically (for a laptop): 1. use some fixed IP address if there's some peer 192.168.0.1 with some given MAC address; 2. otherwise, if an Ethernet cable is plugged in (and only in this case), start a DHCP client; 3. make things still work after a suspend/resume. [...] The average user doesn't know what an IP address, MAC address or DHCP are. There's a reason why d-i defaults to DHCP without even asking now. 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/20110405123456.gu2...@decadent.org.uk
Re: time based freezes
On 04/04/2011 01:15 PM, Piotr Ożarowski wrote: 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 Ack! We need to be able to give our upstreams a fixed release date so they can plan ahead to have their release ready in time. If they don't manage to do so it is not our fault anymore at least. -- 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/4d9b134f.8050...@bzed.de
Re: Moving bash from essential/required to important?
Luk Claes l...@debian.org (04/04/2011): 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 is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) KiBi. signature.asc Description: Digital signature
Making may not be removed and needed
* Steve Langasek vor...@debian.org [110404 19:22]: 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. I think it might be nice if those two aspects could be isolated somehow. This could also reduce the size of some build chroots and the set of packages any boot-strap code has to handle specially[1]. With all the essential stuff only needed for a full system to boot, those are larger than they needed to be. I think e2fsprogs login mount sysvinit sysvinit-utils util-linux and their dependencies (passwd, initscripts, the whole pam stack) are mostly not needed in that set[2]. (Util-linux might have one or two programs one might want to move to another package then, and something for update-rc.d needs to be done). How about giving the old meaning of Essential to packages being Essential: yes and Priority: required and allowing a new state Essential: yes and Priority: important that means a package manager has to make sure its functionality is kept[3] but everything not having a Dependency is still supposed to work (do build chroots, embedded stuff or other things can do without them). Bernhard R. Link [1] bootstrap code essentiall needs to unpack those and all their dependencies manually and then call dpkg to do that again... [2] At least I often build some of my packages in chroots not having any of those. [3] Though in my eyes not removed might suffice. Being able to login always but having no guarantee a sshd is still running and working or that it is still bootable gives not much in my eyes. -- 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/20110405141822.ga6...@pcpool00.mathematik.uni-freiburg.de
Bug#620980: ITP: libgwibber -- gwibber shared library
Package: wnpp Severity: wishlist Owner: Kartik Mistry kar...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libgwibber Version : 0.1.1 Upstream Author : Ken VanDine ken.vand...@canonical.com * URL : http://launchpad.net/gwibber * License : LGPL-3 Programming Lang: C, Vala Description : gwibber shared library libgwibber provides a library for accessing social networks via. gwibber. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2bNPsACgkQoRg/jtECjI1TtQCeL7BVlNDIXTHE92e9hfd9jLY1 +oAAni1zwkozNUE06hskItACIjcz3CdO =5SEG -END PGP SIGNATURE- -- 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/20110405152801.31932.52947.reportbug@localhost
Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
Processing commands for cont...@bugs.debian.org: reassign 620458 general Bug #620458 [base-files] base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp Bug reassigned from package 'base-files' to 'general'. Bug No longer marked as found in versions base-files/6.1. thanks Stopping processing here. Please contact me if you need assistance. -- 620458: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620458 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.130201724313381.transcr...@bugs.debian.org
Re: Bits from the Release Team - Kicking off Wheezy
Hello, On Tue, 5 Apr 2011 13:30:53 +0100 Ben Hutchings b...@decadent.org.uk wrote: Why is that necessary? So far as I can see, the purpose of the state files is: - Let ifup refuse to reapply a configuration (even if it failed to apply it in the first place) - Allow ifdown to take shortcuts, which often don't work Don't know what do you mean when you say 'shortcuts' and how they don't work. You can use multiple configurations in your config file, and do $ ifup eth1=home Then state file will have a record eth1=home, so ifdown eth1 will know which configuration to use to take the interface down. They don't even provide the useful feature of copying the configuration that was applied, in case it is subsequently changed or removed in /etc/network/interfaces. They don't have to. -- WBR, Andrew signature.asc Description: PGP signature
Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
reassign 620458 general thanks On Fri, 1 Apr 2011, Josh Triplett wrote: Package: base-files Version: 6.1 Severity: wishlist /tmp and /var/lock currently allow writes by anyone, with the sticky bit set to only allow removal by the owner. Please consider doing the same for /var/run. That would allow daemons run as non-root users (including those run as part of user sessions) to put their sockets in /var/run. I will be happy to change the default permissions once that every program is modified to support both 755 and 1777 permissions. But until then, this is *hardly* a bug in base-files (as I can't fix it) but a general bug, as it affects a large number of packages, hence the reassign. -- 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/alpine.deb.2.00.1104051722280.21...@cantor.unex.es
Re: Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
Am 05.04.2011 17:30, schrieb Debian Bug Tracking System: Processing commands for cont...@bugs.debian.org: reassign 620458 general Bug #620458 [base-files] base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp Bug reassigned from package 'base-files' to 'general'. Bug No longer marked as found in versions base-files/6.1. Very bad idea imho, I'm strongly against it. The point of /run is not to create a second /tmp, where everyone can write into. daemons running as regular user should either put it's runtime files in $HOME or $XDG_RUNTIME_DIR [1]. The latter is relatively new and I'd rather see us embrace that in Debian and make sure it is setup properly. Michael [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- 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
Updating GPG howto (http://keyring.debian.org/creating-key.html)
Hello list, I'm about to generate a new GPG keypair to supplement my old v3 1024R as suggested by Gunnar Wolf as of 2010-09-14 [1] and I was following the documentation on http://keyring.debian.org/creating-key.html . I'm using GnuPG 1.4.11 from my Debian Wheezy, and a few things have changed since that tutorial was written. I'm not very sure about the security concerns about my decision, so I'm asking experts on the list how the tutorial should be updated for recent GnuPG. 1/ There is no date or GnuPG version on the tutorial. The source (Ana's blog) is more precise, it's 2009-05-10 and GnuPG 1.4. There's a leter update about GnuPG 1.4.0 and higer as of 2009-09. Wouldn't it be more clear if the page explictly mentions the GnuPG versions pertaining to that documentation ? 2/ It is suggested to update gnupg.conf with: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Is it still needed with GnuPG 1.4.11 ? 3/ The -gen-key menu has changed from the tutorial, it is now: Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Again Ana's blog has been updated and it looks legal (and a good idea) to select the (1) option which also generates an ecnryption key in one go. Is that correct ? [1] http://lists.debian.org/debian-devel-announce/2010/09/msg3.html -- 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/1302016515.2757.68.camel@zerohal.local
Re: Bits from the Release Team - Kicking off Wheezy
On Tue, Apr 05, 2011 at 06:34:18PM +0300, Andrew O. Shadoura wrote: Hello, On Tue, 5 Apr 2011 13:30:53 +0100 Ben Hutchings b...@decadent.org.uk wrote: Why is that necessary? So far as I can see, the purpose of the state files is: - Let ifup refuse to reapply a configuration (even if it failed to apply it in the first place) - Allow ifdown to take shortcuts, which often don't work Don't know what do you mean when you say 'shortcuts' and how they don't work. You can use multiple configurations in your config file, and do $ ifup eth1=home Then state file will have a record eth1=home, so ifdown eth1 will know which configuration to use to take the interface down. ifdown should not *need* to know how the interface was brought up. And given that many people apparently like ifup because they can change the active configuration without it interfering, it would be a good thing if ifdown could cope with that too. (It can do, within some limits. But in general, it cannot.) They don't even provide the useful feature of copying the configuration that was applied, in case it is subsequently changed or removed in /etc/network/interfaces. They don't have to. So I just imagined that ifdown completely fails if this is done? 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/20110405155902.gw2...@decadent.org.uk
Re: Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
On Apr 05, Michael Biebl bi...@debian.org wrote:
Very bad idea imho, I'm strongly against it.
The point of /run is not to create a second /tmp, where everyone can write
into.
Agreed, I really do not want to consider the security implications of a
world-writeable {,/var}/run.
Programs which use /run are supposed to use a subdirectory anyway.
--
ciao,
Marco
signature.asc
Description: Digital signature
Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
sorry for a blunt follow-up -- wouldn't making /var/run writable by regular mortals ask for security concerns if an attacker starts pre-creating files/pipes trying to steal the communications of daemons spawned by root or just ruin some data on the system by symlinking against root-owned files? On Tue, 05 Apr 2011, Santiago Vila wrote: /tmp and /var/lock currently allow writes by anyone, with the sticky bit set to only allow removal by the owner. Please consider doing the same for /var/run. That would allow daemons run as non-root users (including those run as part of user sessions) to put their sockets in /var/run. I will be happy to change the default permissions once that every program is modified to support both 755 and 1777 permissions. But until then, this is *hardly* a bug in base-files (as I can't fix it) but a general bug, as it affects a large number of packages, hence the reassign. -- =--= Keep in touch www.onerussian.com Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic -- 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/20110405163159.gt6...@onerussian.com
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): 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 is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) -- 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: Bits from the Release Team - Kicking off Wheezy
On Tue, Apr 05, 2011 at 04:59:02PM +0100, Ben Hutchings wrote:
ifdown should not *need* to know how the interface was brought up.
And given that many people apparently like ifup because they can
change the active configuration without it interfering, it would be
a good thing if ifdown could cope with that too. (It can do, within
some limits. But in general, it cannot.)
In complicated cases, ifdown will definitely need to know how the
interface was brought up. The configuration allows specification of
arbitrary commands which may not be react well by simply pulling the
interface down without running the specified {pre-,,post-}down commands.
That being said, ifdown does have a --force option if you must.
They don't even provide the useful feature of copying the
configuration that was applied, in case it is subsequently changed or
removed in /etc/network/interfaces.
They don't have to.
So I just imagined that ifdown completely fails if this is done?
This might be a nice feature but I'm not sure how feasible it is. It is
possible that a user may change the configuration to adjust what happens
when a currently running interface is brought down. When they run ifdown
on that interface, they may be confused when the old configuration is
used to bring down the interface simply because that was the
configuration used to bring up the interface.
--
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/20110405164818.ga26...@mail.tuxags.com
Re: time based freezes
* Bernd Zeimetz be...@bzed.de [2011-04-05 15:04]: On 04/04/2011 01:15 PM, Piotr Ożarowski wrote: 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 Ack! We need to be able to give our upstreams a fixed release date so they can plan ahead to have their release ready in time. If they don't manage to do so it is not our fault anymore at least. s/release date/freeze date/ and I agree. 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/20110405165549.gf16...@anguilla.debian.or.at
Re: replacement of merkel services in DDPortfolio
On Tue, 05 Apr 2011, Jan Dittberner wrote: I changed an entry in the ddportfolioservice [1] to reflect the new location to lookup DD assigned debian.net domain names (Paul: thanks for the Wiki edit). There are some more merkel URLs that stopped working. Do you know whether there are replacements on other Debian hosts? The URLs in question are: * all messages (i.e., full text search for developer name on all bug logs) http://merkel.debian.org/~don/cgi/search.cgi?phrase=Jan+Dittberner;search=search This really should have been using http://bugs.debian.org/cgi/search.cgi the entire time; I haven't had a chance yet to bring up estraier on busoni to get this working, but I will do so shortly. Don Armstrong -- DIE! -- Maritza Campos http://www.crfh.net/d/20020601.html http://www.donarmstrong.com http://rzlab.ucr.edu -- 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/20110405165810.gc4...@rzlab.ucr.edu
Re: Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
Am 05.04.2011 18:29, schrieb Marco d'Itri:
On Apr 05, Michael Biebl bi...@debian.org wrote:
Very bad idea imho, I'm strongly against it.
The point of /run is not to create a second /tmp, where everyone can write
into.
Agreed, I really do not want to consider the security implications of a
world-writeable {,/var}/run.
Programs which use /run are supposed to use a subdirectory anyway.
Yeah. Daemons which drop privileges would have a properly owned subdirectory in
/run. Such a subdirectory would be setup by a privileged process. Usually that
is done in the sysv init script itself, although I'd like us to provide a more
declarative mechanism for that.
Cheers,
Michael
--
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: Moving bash from essential/required to important?
On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): 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 is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? 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/20110405170908.gx3...@radis.liafa.jussieu.fr
Re: time based freezes
On Mon, Apr 4, 2011 at 3:38 AM, Carsten Hey cars...@debian.org wrote: 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. Please, *NEVER* do fall or summer or winter. Remember that Debian is developed all around the world, and half the world has the opposite seasons that you have. You can say December and you have a month of leeway to then decide, or November-December to have two months. But please, please, please, no seasonal releases. -- Besos, Marga -- 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=v7u0cjgna7qygbjkajebx-ws...@mail.gmail.com
Bug#620458: Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
On Tue, 05 Apr 2011, Michael Biebl wrote:
Am 05.04.2011 17:30, schrieb Debian Bug Tracking System:
Processing commands for cont...@bugs.debian.org:
reassign 620458 general
Bug #620458 [base-files] base-files: Please make /var/run world-writable
and sticky, like /var/lock and /tmp
Bug reassigned from package 'base-files' to 'general'.
Bug No longer marked as found in versions base-files/6.1.
Very bad idea imho, I'm strongly against it.
The point of /run is not to create a second /tmp, where everyone can write
into.
daemons running as regular user should either put it's runtime files in $HOME
or
$XDG_RUNTIME_DIR [1].
Since the init scripts get run as root, they should create a
subdirectory of {/var,}/run, chown/chmod it appropriately, and then
start the daemon. [If we're talking about things that get started by a
normal user, then they should use $HOME (or some other more specific
runtime directory.)]
Don Armstrong
--
They say when you embark on a journey
of revenge
dig two graves.
They underestimate me.
-- a softer world #560
http://www.asofterworld.com/index.php?id=560
http://www.donarmstrong.com http://rzlab.ucr.edu
--
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/20110405170310.gd4...@rzlab.ucr.edu
dh-make: don't install .la files in -dev library packages
Package: dh-make Severity: wishlist Hi, On 03/04/11 14:57, Mathieu Parent wrote: dh-make 0.58 install .la files by default (/usr/share/debhelper/dh_make/debianl/package-dev.install contains usr/lib/*.la) Should we change this also? Since policy discourages shipping .la files, and there's a release goal for that, please stop adding *.la files in libfoo-dev.install. It can be manually added in the rare cases where it's really required. Thanks, Emilio -- 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/4d9b4b10.3050...@debian.org
Re: Bug#620458: Processed: Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
Am 05.04.2011 19:03, schrieb Don Armstrong:
On Tue, 05 Apr 2011, Michael Biebl wrote:
Am 05.04.2011 17:30, schrieb Debian Bug Tracking System:
Processing commands for cont...@bugs.debian.org:
reassign 620458 general
Bug #620458 [base-files] base-files: Please make /var/run world-writable
and sticky, like /var/lock and /tmp
Bug reassigned from package 'base-files' to 'general'.
Bug No longer marked as found in versions base-files/6.1.
Very bad idea imho, I'm strongly against it.
The point of /run is not to create a second /tmp, where everyone can write
into.
daemons running as regular user should either put it's runtime files in
$HOME or
$XDG_RUNTIME_DIR [1].
Since the init scripts get run as root, they should create a
subdirectory of {/var,}/run, chown/chmod it appropriately, and then
start the daemon. [If we're talking about things that get started by a
normal user, then they should use $HOME (or some other more specific
runtime directory.)]
Yeah agreed, sorry that my initial email wasn't entirely clear, see my
clarification in 4d9b4c21.6010...@debian.org
--
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!)
Hello, On Tue, 5 Apr 2011 14:31:40 +0200 Vincent Lefevre vinc...@vinc17.net wrote: [About the general problem of documentation] The problem is to find the correct tools and the correct documentation. For instance, imagine the average user who wants for Ethernet (eth0), to do the following automatically (for a laptop): 1. use some fixed IP address if there's some peer 192.168.0.1 with some given MAC address; 2. otherwise, if an Ethernet cable is plugged in (and only in this case), start a DHCP client; 3. make things still work after a suspend/resume. I now know how to do this. But I still wonder what documentation a user should read to achieve such a configuration. It is normal that a user may want to use his laptop from network to network and things work without manual reconfiguration. Of course, man guessnet. Just few lines. mapping eth1 script guessnet-ifupdown map default: dhcp iface eth-home inet static test peer address 192.168.0.1 mac ... ... iface dhcp inet dhcp The last requirement is fulfilled by means of installing ifplugd. -- WBR, Andrew signature.asc Description: PGP signature
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
On 2011-04-05, Andrew O. Shadoura bugzi...@tut.by wrote: Of course, man guessnet. Just few lines. Last time I looked guessnet was orphaned, though. Kind regards Philipp Kern -- 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/slrnipmlga.gou.tr...@kelgar.0x539.de
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
Simon McVittie s...@debian.org writes: * lintian should warn (error?) if a binary package has libraries in a multiarch directory and doesn't pre-depend on multiarch-support Yes, this is what we did for the X.org transition and it seemed to work reasonably well. -- 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/87k4f8zivs@windlord.stanford.edu
Re: Moving bash from essential/required to important?
On Tue, Apr 05, 2011 at 07:09:08PM +0200, Julien Cristau wrote: On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): 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 is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? They probably all want to do this. But while removing dash and coreutils from Essential is probably not practical at present, removing just bash would still go a long way to help since that's at least /one/ of these packages for which we would have a contract saying Debian supports removing it. If the package gets pulled into your environment as a dependency, you know what dependency to fix. If the package is pulled in because it's Essential and you want to remove it, you have to constantly inspect the system to make sure nothing is using it. -- 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!)
Hi, Am Dienstag, den 05.04.2011, 17:48 + schrieb Philipp Kern: On 2011-04-05, Andrew O. Shadoura bugzi...@tut.by wrote: Of course, man guessnet. Just few lines. Last time I looked guessnet was orphaned, though. but still very useful and allowing me to have a great network setup that, once set up, automatically and invisibly adjust to whatever place I am. Greetings, Joachim PS: This e-mail is relatively useless. To lessen this a bit: Kudos to Enrico for creating guessnet! -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing
Package: general Severity: normal Swap usage prior to 2.6.26-2 upgrade was a relatively constant 0 Post 2.6.26-2 upgrade the usage is usually up into 300MB, not actively swapping however and doesn't seem to be affecting performance, but nagios is none to happy about swap being used. The problem seems relegated to a handful of machines, although there may be some usage pattern I'm not seeing but otherwise there is no difference between systems that are swap happy and those where swap stays 0, same make/model, same build configuration, packages, client code, etc. Like I mentioned, it doesn't seem to impact performance, but it is certainly a change from the norm. See this on about 8 systems out of a couple hundred, and the same 8 will almost always start using swap slowly over time until a plateu is reached of around 300-500MB, depending on the system. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- 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/20110405180845.13396.76364.report...@www05.wernerpublishing.ml.zerolag.com
Re: Making may not be removed and needed
On Tue, Apr 05, 2011 at 04:18:22PM +0200, Bernhard R. Link wrote: * Steve Langasek vor...@debian.org [110404 19:22]: 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. I think it might be nice if those two aspects could be isolated somehow. This could also reduce the size of some build chroots and the set of packages any boot-strap code has to handle specially[1]. With all the essential stuff only needed for a full system to boot, those are larger than they needed to be. I think e2fsprogs login mount sysvinit sysvinit-utils util-linux and their dependencies (passwd, initscripts, the whole pam stack) are mostly not needed in that set[2]. (Util-linux might have one or two programs one might want to move to another package then, and something for update-rc.d needs to be done). I think this is a false optimization. How does reducing the set of packages in a buildd chroot help anything? A typical package has build-dependencies many times the size of the Essential set. -- 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!)
#include hallo.h * Kelly Clowers [Mon, Apr 04 2011, 02:06:01PM]: On Mon, Apr 4, 2011 at 07:29, Sune Vuorela nos...@vuorela.dk wrote: 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 So, and where exactly is your bug report? Don't you think that the developers deserve that minimum of respect that you tell them (yes, them, not some blog/mailing list) that there is a problem? Regards, Eduard. -- Ganneff kde und tastatur? passt doch nicht mit dem nutzerprofil windepp zusammen :) -- 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/20110405182524.ga25...@rotes76.wohnheim.uni-kl.de
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, Apr 05, 2011 at 11:12:29AM +0100, Simon McVittie wrote:
On Tue, 05 Apr 2011 at 11:12:54 +0200, Adam Borowski wrote:
On Sat, Apr 02, 2011 at 12:36:05AM -0700, Steve Langasek wrote:
Specifically, the plan is that any package in wheezy shipping a runtime
library in a multiarch directory should declare a Pre-Depends on the
metapackage 'multiarch-support'.
And the dependency would be added by either dpkg-dev, debhelper, or
dpkg-shlibdeps rather than being added to every single library by hand,
right?
Because debhelper doesn't add any Pre-Depends yet, there's nowhere to put
the new dependency that would automatically be picked up. I believe the
current plan is that:
* debhelper adds multiarch-support to a new
${misc:Pre-Depends} substvar (which must be added to the library by hand)
* this is only relevant to packages that divert files into multiarch
directories, which would only happen with package-specific changes anyway
(bumping the debhelper compat level to 9, if nothing else)
* lintian should warn (error?) if a binary package has libraries in a
multiarch
directory and doesn't pre-depend on multiarch-support
Yes, it should. I think this should actually be an immediate archive reject
for any package installing to the multiarch lib path without the correct
pre-depends, since (on i386, anyway) the missing pre-dep will break partial
upgrades in a Bad Way.
--
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#620993: marked as done (general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
Your message dated Tue, 5 Apr 2011 19:45:28 +0100 with message-id 20110405184528.gx2...@decadent.org.uk and subject line Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing has caused the Debian Bug report #620993, regarding general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 620993: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620993 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: general Severity: normal Swap usage prior to 2.6.26-2 upgrade was a relatively constant 0 Post 2.6.26-2 upgrade the usage is usually up into 300MB, not actively swapping however and doesn't seem to be affecting performance, but nagios is none to happy about swap being used. The problem seems relegated to a handful of machines, although there may be some usage pattern I'm not seeing but otherwise there is no difference between systems that are swap happy and those where swap stays 0, same make/model, same build configuration, packages, client code, etc. Like I mentioned, it doesn't seem to impact performance, but it is certainly a change from the norm. See this on about 8 systems out of a couple hundred, and the same 8 will almost always start using swap slowly over time until a plateu is reached of around 300-500MB, depending on the system. -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash ---End Message--- ---BeginMessage--- On Tue, Apr 05, 2011 at 11:08:45AM -0700, Daniel Gary wrote: Package: general Severity: normal Swap usage prior to 2.6.26-2 upgrade was a relatively constant 0 Post 2.6.26-2 upgrade the usage is usually up into 300MB, not actively swapping however and doesn't seem to be affecting performance, but nagios is none to happy about swap being used. Then fix the NAGIOS configuration. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus ---End Message---
Re: Proposed pre-depends addition: all multiarched libs - multiarch-support
On Tue, Apr 05, 2011 at 11:25:44AM +0100, Neil Williams wrote:
Lintian error (and an ftpmaster REJECT) if debhelper compat 9 is set
with no ${misc:PreDepends} set because that prevents the
multiarch-support addition. A failure to convert ${misc:PreDepends} to
multiarch-support would be a debhelper bug and seems quite unlikely -
but worth checking at ftpmaster level, possibly.
There's no basis for making this an ftpmaster reject. The archive-critical
check can be done by inspecting the binary packages only.
Lintian error (and an ftpmaster REJECT) if a binary package (not just
a library) has multiarch paths without debhelper compat 9. (This
protects against uploading packages converted with tools like
dpkg-cross -M -A (= 2.6.3).)
Absolutely not. Packages are not required to use debhelper compat 9 as a
prerequisite for multiarch, it's just the easiest way to get there *if*
you're using dh(1).
That way, if multiarch-support is no longer needed as a Pre-Depends, the
lintian error is still correct (but can be downgraded with only a
change in lintian) and the rest of the archive packages need no further
changes. The next package rebuild after we decide that
multiarch-support becomes a no-op and ${misc:PreDepends} goes back to
being the empty string automatically, via a change in debhelper.
That's the preferred way to do it, but there's no reason at all to penalize
maintainers with an archive reject for not using this preferred way.
--
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: Moving bash from essential/required to important?
On Tue, 5 Apr 2011 19:09:08 +0200, Julien Cristau jcris...@debian.org wrote: On Tue, Apr 5, 2011 at 09:41:24 -0700, Steve Langasek wrote: On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote: Luk Claes l...@debian.org (04/04/2011): 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 is the most obvious reason to degrade bash to Priority: important? (I can understand shell maintainers would like to get bash out of their way, but how many (other) people really want to get rid of it?) Anybody doing development for embedded systems. :) Which of those people don't also want to get rid of dash and coreutils and use busybox instead? And your point is? If both dash and busybox provide posix shell, and removing bash from essential highlights those packages that use bashisms unnecessarily, and so encourage some or all of those to be rendered in posix instead, then the world will have become a better place for embedded developers. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgp7fCEgLI286.pgp Description: PGP signature
Bug#620993: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
I have, but fixing monitoring to suit edge cases created from a recent upgrade doesn't make the edge cases non-issues. This is still an issue whether you want to hide it under nagios or not, so I'd appreciate a little more assistance in finding the problem beyond fixing nagios. If you go the doctors for a broken leg he doesn't just tell you well try not to walk on it. The upgrades to 2.6.26-2 created anomalies, anomalies are bad. On 4/5/2011 11:48 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the general package: #620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing It has been closed by Ben Hutchingsb...@decadent.org.uk. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Ben Hutchingsb...@decadent.org.uk by replying to this email. -- 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/4d9b6a40.1050...@gmail.com
Re: Moving bash from essential/required to important?
Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * 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. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. And third. The correct way to manage /bin/sh is as a configuration file. That means: * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. Policy 10.7.4 (Sharing configuration files) spells this out. It doesn't have much to do with whether dependencies on bash are made explicit. Hope that helps, Jonathan -- 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/20110405210530.GA13445@elie
Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * 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. Also seems to be orthogonal. I agree that this seems to be orthogonal at first, and even second, sight. And third. The correct way to manage /bin/sh is as a configuration file. That means: * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. Policy 10.7.4 (Sharing configuration files) spells this out. It doesn't have much to do with whether dependencies on bash are made explicit. Well, that will only happen when it's cristal clear that it's guaranteed that /bin/sh exists and is functional at all times in such a scenario. You are welcome to implement such a solution, but if it does not meet the above criterion, it will very probably not be adopted. 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/4d9b8580.6010...@debian.org
Bug#620993: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
On 05/04/2011 21:15, Daniel Gary wrote: I have, but fixing monitoring to suit edge cases created from a recent upgrade doesn't make the edge cases non-issues. This is still an issue whether you want to hide it under nagios or not, I do not understand the issue. You have some swap and you expect the kernel *not* to use it ? *This* would be a bug. It is better that the kernel swap out (parts of) processes it never uses and keep the RAM for processes that need it. Regards, Vincent -- 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/4d9b7f81.7040...@debian.org
Re: Bug#620943: ITP: evtest -- utility to monitor input device events
On Tue, 5 Apr 2011 13:14:01 +0200, Julien Cristau jcris...@debian.org wrote: On Tue, Apr 5, 2011 at 09:41:13 +0200, Stephen Kitt wrote: * Package name: evtest Version : 1.27 Upstream Author : Peter Hutterer peter.hutte...@redhat.com * URL : http://cgit.freedesktop.org/evtest/ * License : GPLv2 Programming Lang: C Description : utility to monitor input device events evtest monitors an input device, displaying all the events it generates. a Linux input device maybe... Indeed, thanks for pointing that out; I'll change the description and the Architecture: field. It can be used to determine mice button bindings, keymaps for exotic keyboards... It is commonly used to debug issues with input devices in X.Org. Thanks for picking this up! You're welcome! Once I found out about Peter's repository it seemed like the obvious thing to do. Regards, Stephen -- 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/20110405230141.7c81b...@sk2.org
Bug#620993: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
I'm not arguing that, I fully expect the kernel to use it to swap *if needed*. And if this was 20MB of swap, or maybe 100MB, ok, sure, the kernel might be swapping old pages out, but 300MB+ swapping out in 2.6.26-2 where 0MB swapped out in 2.6.26-1, and I can't find anything in the kernel.org or debian kernel changelogs referencing a change along these lines doesn't really scream working as expected. More annoying that the swap space never decreases unless swapoff/swapon occurs The closest thing I can find was a patch from Mel Gorman, but that doesn't explain how the swap space is getting used in the first place, or more how 2 otherwise identical machines have different amounts used, 0 and in the case I'm debugging ATM 312MB, Same make/model, same debian lenny build, they're clones for all intents and purposes. The only thing on these systems that has changed was 2.6.26-1 to 2.6.26-2, and swap wasn't being used to this extent, or staying used if it was used, prior to 2.6.26-2. Now it almost seems that once its used it doesn't get freed. On 4/5/2011 1:45 PM, Vincent Danjean wrote: On 05/04/2011 21:15, Daniel Gary wrote: I have, but fixing monitoring to suit edge cases created from a recent upgrade doesn't make the edge cases non-issues. This is still an issue whether you want to hide it under nagios or not, I do not understand the issue. You have some swap and you expect the kernel *not* to use it ? *This* would be a bug. It is better that the kernel swap out (parts of) processes it never uses and keep the RAM for processes that need it. Regards, Vincent -- 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/4d9b86fd.9000...@gmail.com
Re: Bug#620993: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
On Wed, 6 Apr 2011, Daniel Gary dgary1...@gmail.com wrote: I'm not arguing that, I fully expect the kernel to use it to swap *if needed*. And if this was 20MB of swap, or maybe 100MB, ok, sure, the kernel might be swapping old pages out, but 300MB+ swapping out in 2.6.26-2 where 0MB Using more memory for disk cache and less for storing rarely used pages sounds like a performance optimisation. Anyway I don't think that there's going to be much interest in performance- tuning of Lenny kernels now that Squeeze is released. If you want help in tuning Lenny then probably debian-user or your local LUG mailing list would be the best option. -- 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/201104060747.09658.russ...@coker.com.au
Re: Bug#620458: base-files: Please make /var/run world-writable and sticky, like /var/lock and /tmp
On Wed, 6 Apr 2011, Yaroslav Halchenko deb...@onerussian.com wrote: sorry for a blunt follow-up -- wouldn't making /var/run writable by regular mortals ask for security concerns if an attacker starts pre-creating files/pipes trying to steal the communications of daemons spawned by root or just ruin some data on the system by symlinking against root-owned files? There have been security issues with daemons using /tmp for Unix domain sockets in the past. -- 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/201104060748.16848.russ...@coker.com.au
Bug#620993: closed by Ben Hutchings b...@decadent.org.uk (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)
On 4/5/2011 2:47 PM, Russell Coker wrote: On Wed, 6 Apr 2011, Daniel Garydgary1...@gmail.com wrote: I'm not arguing that, I fully expect the kernel to use it to swap *if needed*. And if this was 20MB of swap, or maybe 100MB, ok, sure, the kernel might be swapping old pages out, but 300MB+ swapping out in 2.6.26-2 where 0MB Using more memory for disk cache and less for storing rarely used pages sounds like a performance optimisation. Fully agree, but I don't see anything in the changelog where that optimization occurred. So while it sounds great in theory I can't back it with the patches that went into 2.6.26-2 from 2.6.26-1. Although it is what I've been telling the client is the likely case for lack of a better answer and no loss in performance on the system. Anyway I don't think that there's going to be much interest in performance- tuning of Lenny kernels now that Squeeze is released. Unfortunately an upgrade to Squeeze is a bit more involved than the upgrade windows we have available, but I think may be the only option at this point, but that's kind of like fixing a sparkplug that doesn't fire by buying a new car, sure it'll probably do the job in the end, but that doesn't really explain why the sparkplug doesn't fire. But certainly a better reason to close the ticket than the previous one, doesn't make it invalid, just makes it a wontfix. I'd rather it be closed for someone being lazy than someone being dismissive, a good sysadmin is a lazy sysadmin after all. If you want help in tuning Lenny then probably debian-user or your local LUG mailing list would be the best option. Its not a tuning issue, its a change in a vacuum, more a freakish annoyance than anything, it performs fine, we benchmarked before after and didn't notice any change either way other than these systems that swap, well... swap. The support tech in me says screw it, it works, but the engineer in me says hmm, thats funny. -- 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/4d9b9510.5060...@gmail.com
Re: replacement of merkel services in DDPortfolio
On Tue, 05 Apr 2011, Jan Dittberner wrote: * Group membership information ssh merkel.debian.org id jandd echo -n 'uid: ' read uid ldapsearch -LLL -x -h db.debian.org -b dc=debian,dc=org uid=$uid supplementaryGid On any host. On debian.org machines you need not use -h and -b. weasel -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- 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/20110405231817.gu16...@anguilla.noreply.org
Bug#620957: general: Would you be so kind to include Frandom in the Debian Repositories?
reassign 620957 wnpp retitle 620957 RFP: frandom: kernel module for generating PRNG data thanks On 05-Apr-2011, Ruben wrote: I would like to see Frandom in the Debian repositories. Frandom is a kernel module for pseudo-random data generation, much as random and urandom, but works incredibly fast. Thank you for your request, and for a brief description of the package. The correct procedure for such requests is a “Request For Package” (RFP), assigned against the ‘wnpp’ pseudo-package. The next step is to interest someone (maybe you?) to become the maintainer for that package in Debian, and to do the work of getting it packaged and accepted. I have changed this report accordingly. Thank you for your interest in improving Debian. -- \ “It is not enough to have a good mind. The main thing is to use | `\ it well.” —Rene Descartes | _o__) | Ben Finney b...@benfinney.id.au signature.asc Description: Digital signature
Processed: Re: Bug#620957: general: Would you be so kind to include Frandom in the Debian Repositories?
Processing commands for cont...@bugs.debian.org:
reassign 620957 wnpp
Bug #620957 {Done: Ben Hutchings b...@decadent.org.uk} [general] general:
Would you be so kind to include Frandom in the Debian Repositories?
Bug reassigned from package 'general' to 'wnpp'.
retitle 620957 RFP: frandom: kernel module for generating PRNG data
Bug #620957 {Done: Ben Hutchings b...@decadent.org.uk} [wnpp] general: Would
you be so kind to include Frandom in the Debian Repositories?
Changed Bug title to 'RFP: frandom: kernel module for generating PRNG data'
from 'general: Would you be so kind to include Frandom in the Debian
Repositories?'
thanks
Stopping processing here.
Please contact me if you need assistance.
--
620957: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620957
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
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/handler.s.c.13020472957305.transcr...@bugs.debian.org
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
* Luk Claes [2011-04-05 23:11 +0200]: On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: * 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. The correct way to manage /bin/sh is as a configuration file. Of course it is. * dash would stop shipping /bin/sh in its data.tar * bash would stop shipping /bin/sh in its data.tar How would debootstrap be able to run the preinst scripts without a working /bin/sh, unless it runs bash's binary one first? * an essential package (doesn't matter which --- maybe debianutils) should take care of allowing other shells to influence where /bin/sh points. update-alternatives is (among other things) because of the indirection it uses the wrong tool, but a part of it fits rather good. Such a tool would need to support priorities to select per default dash as /bin/sh, if dash is not installed it would select bash and if both are missing it would select an other shell. It would also need to assure that whilst it is running /bin/sh is always functional. Passing a shell to it that is not included in /etc/shells could lead to failing of this tool, unless --force is used. Well, that will only happen when it's cristal clear that it's guaranteed that /bin/sh exists and is functional at all times in such a scenario. Guaranteeing that /bin/sh exists and is functional during debootstrap, even before any maintainer script has been run, could be archived if every system shell would provide /bin/sh pointing to itself. To avoid file conflicts, all but the one whose preinst is run first (finding a clever way to detect this shouldn't be that hard) could divert their /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name would be) finally takes over managing /bin/sh, it could divert the remaining /bin/sh away and replace it with a symlink not known to the packaging system. Running update-shells in postinst and prerm (and never in the other two) would additionally be required to ensure that /bin/sh is always functional. 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/20110405235520.ga5...@furrball.stateful.de
Re: time based freezes
On Wed, Apr 6, 2011 at 1:14 AM, Margarita Manterola margamanter...@gmail.com wrote: Please, *NEVER* do fall or summer or winter. Remember that Debian is developed all around the world, and half the world has the opposite seasons that you have. You can say December and you have a month of leeway to then decide, or November-December to have two months. But please, please, please, no seasonal releases. Indeed. Also, the word fall is not universally known around the world so using it makes the freeze time even less intelligible. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/BANLkTin=ubHCs�x88gqjnimyeovs-...@mail.gmail.com
Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)
On Tue, Apr 05, 2011 at 05:15:15PM +0200, Vincent Caron wrote: 2/ It is suggested to update gnupg.conf with: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed Is it still needed with GnuPG 1.4.11 ? This isn't strictly needed with any version of GnuPG. However, these settings choose algorithms which are known to be stronger (avoiding MD5 and the mandatory but somewhat weakened SHA1). Setting default-preference-list specifies which algorithms you prefer in your key's self-signature (which you can always change later). Implementations are forbidden from using algorithms (other than the default must-implement ones) that you do not specify in your self-signature. Using cert-digest-algo chooses the algorithm you will use in signing keys. And finally, personal-digest-preferences is the algorithm you will use when signing data. If you know what you're doing, you can choose the algorithms you prefer here instead of these. If you don't, these are fine choices. 3/ The -gen-key menu has changed from the tutorial, it is now: Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Again Ana's blog has been updated and it looks legal (and a good idea) to select the (1) option which also generates an ecnryption key in one go. Is that correct ? Yes. It creates an RSA main key (used for signing other keys and possibly data) and an RSA encryption-only subkey. Some people use a subkey for signing as well, but that can be generated later. I recommend using the largest size possible, which IIRC is 4096 bits. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]
On 04/06/2011 01:55 AM, Carsten Hey wrote: * Luk Claes [2011-04-05 23:11 +0200]: On 04/05/2011 11:05 PM, Jonathan Nieder wrote: Carsten Hey wrote: * Steve Langasek [2011-04-04 19:37 -0700]: On Tue, Apr 05, 2011 at 02:00:36AM +0200, Carsten Hey wrote: Guaranteeing that /bin/sh exists and is functional during debootstrap, even before any maintainer script has been run, could be archived if every system shell would provide /bin/sh pointing to itself. To avoid file conflicts, all but the one whose preinst is run first (finding a clever way to detect this shouldn't be that hard) could divert their /bin/sh to /bin/sh.$SHELL. When update-shell (or whatever it's name would be) finally takes over managing /bin/sh, it could divert the remaining /bin/sh away and replace it with a symlink not known to the packaging system. That unfortunately does not work as diversions are only meant to be used when 2 packages provide the same file. One of the problems being what to do when you remove one of the shells (for instance the one providing /bin/sh)... 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/4d9bf825.4090...@debian.org
Re: Back to technical discussion? Yes! (was: network-manager as default? No!)
Le mardi 05 avril 2011 à 14:31 +0200, Vincent Lefevre a écrit : For instance, imagine the average user who wants for Ethernet (eth0), to do the following automatically (for a laptop): 1. use some fixed IP address if there's some peer 192.168.0.1 with some given MAC address; There are several hacks to do that (like guessnet or laptop-net), but I don’t think this can work correctly in the general case with IPv4. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
