Re: Back to technical discussion? Yes!

[Stanislav Maslovski]

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!

[Tollef Fog Heen]

]] 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!)

[Rens Houben]

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

[Neil Williams]

On Mon, 4 Apr 2011 16:12:42 -0700
Steve Langasek  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

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 


* Package name: evtest
  Version : 1.27
  Upstream Author : Peter Hutterer 
* 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?

[Bastien ROUCARIES]

On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh  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?

[Lars Wirzenius]

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!

[Faidon Liambotis]

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!

[Stanislav Maslovski]

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

[Dmitry Katsubo]

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!

[Stanislav Maslovski]

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?

[Roger Leigh]

On Tue, Apr 05, 2011 at 09:36:14AM +0200, Bastien ROUCARIES wrote:
> On Mon, Apr 4, 2011 at 8:43 PM, Roger Leigh  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?

[Andreas Rottmann]

Goswin von Brederlow  writes:

> Lars Wirzenius  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 -- 


-- 
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?

[Carsten Hey]

* 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

[Bjørn Mork]

Ben Hutchings  writes:
> On Sat, 2011-04-02 at 23:07 +0200, Bjørn Mork wrote:
>> Josselin Mouette  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?

[Emilio Pozuelo Monfort]

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

[Adam Borowski]

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

[Simon McVittie]

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?

[Carsten Hey]

* 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

[Neil Williams]

On Tue, 5 Apr 2011 11:12:29 +0100
Simon McVittie  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!

[Bjørn Mork]

Steve Langasek  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.

[Ben Hutchings]

On Tue, 2011-04-05 at 09:41 +0800, Paul Wise wrote:
> On Mon, Apr 4, 2011 at 11:03 PM, Ben Hutchings  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

[Ben Hutchings]

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

[Neil Williams]

On Tue, 05 Apr 2011 11:47:01 +0100
Ben Hutchings  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

[TANIGUCHI Takaki]

Package: wnpp
Owner: tak...@debian.org
Severity: wishlist

* Package name: libdata-amf-perl
  Version : 0.09-1
  Upstream Author : Daisuke Murase 
* 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

[Julien Cristau]

On Tue, Apr  5, 2011 at 09:41:13 +0200, Stephen Kitt wrote:

> * Package name: evtest
>   Version : 1.27
>   Upstream Author : Peter Hutterer 
> * 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

[Andrew O. Shadoura]

Hello,

On Mon, 4 Apr 2011 11:56:15 +0100
Ben Hutchings  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

[Jan Dittberner]

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

[Andrew O. Shadoura]

Hello,

On Tue, 5 Apr 2011 14:16:30 +0300
"Andrew O. Shadoura"  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

[Julien Cristau]

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

[Neil McGovern]

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!

[Ben Armstrong]

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

[Paul Wise]

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?

[Ruben]

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

[Philipp Kern]

On 2011-04-05, Julien Cristau  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

[Ben Hutchings]

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  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!)

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - 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?)

[Debian Bug Tracking System]

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
--- Begin Message ---
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 ---
--- Begin Message ---
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!)

[Ben Hutchings]

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

[Bernd Zeimetz]

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?

[Cyril Brulebois]

Luk Claes  (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

[Bernhard R. Link]

* Steve Langasek  [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

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: libgwibber
  Version : 0.1.1
  Upstream Author : Ken VanDine 
* 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

[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.
> 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

[Andrew O. Shadoura]

Hello,

On Tue, 5 Apr 2011 13:30:53 +0100
Ben Hutchings  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

[Santiago Vila]

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

[Michael Biebl]

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)

[Vincent Caron]

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

[Ben Hutchings]

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  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

[Marco d'Itri]

On Apr 05, Michael Biebl  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

[Yaroslav Halchenko]

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?

[Steve Langasek]

On Tue, Apr 05, 2011 at 03:14:12PM +0200, Cyril Brulebois wrote:
> Luk Claes  (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

[Kyle Willmon]

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

[Martin Wuertele]

* Bernd Zeimetz  [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

[Don Armstrong]

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

[Michael Biebl]

Am 05.04.2011 18:29, schrieb Marco d'Itri:
> On Apr 05, Michael Biebl  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?

[Julien Cristau]

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  (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

[Margarita Manterola]

On Mon, Apr 4, 2011 at 3:38 AM, Carsten Hey  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

[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.)]


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

[Emilio Pozuelo Monfort]

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

[Michael Biebl]

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!)

[Andrew O. Shadoura]

Hello,

On Tue, 5 Apr 2011 14:31:40 +0200
Vincent Lefevre  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!)

[Philipp Kern]

On 2011-04-05, Andrew O. Shadoura  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

[Russ Allbery]

Simon McVittie  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)   


-- 
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?

[Steve Langasek]

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  (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!)

[Joachim Breitner]

Hi,

Am Dienstag, den 05.04.2011, 17:48 + schrieb Philipp Kern:
> On 2011-04-05, Andrew O. Shadoura  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

[Daniel Gary]

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

[Steve Langasek]

On Tue, Apr 05, 2011 at 04:18:22PM +0200, Bernhard R. Link wrote:
> * Steve Langasek  [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!)

[Eduard Bloch]

#include 
* Kelly Clowers [Mon, Apr 04 2011, 02:06:01PM]:
> On Mon, Apr 4, 2011 at 07:29, Sune Vuorela  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.
-- 
 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

[Steve Langasek]

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)

[Debian Bug Tracking System]

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
--- Begin Message ---
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 ---
--- Begin Message ---
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

[Steve Langasek]

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?

[Philip Hands]

On Tue, 5 Apr 2011 19:09:08 +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  (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 (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)

[Daniel Gary]

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 Hutchings.

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 
Hutchings  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?

[Jonathan Nieder]

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?]

[Luk Claes]

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 (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)

[Vincent Danjean]

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

[Stephen Kitt]

On Tue, 5 Apr 2011 13:14:01 +0200, Julien Cristau  wrote:
> On Tue, Apr  5, 2011 at 09:41:13 +0200, Stephen Kitt wrote:
> 
> > * Package name: evtest
> >   Version : 1.27
> >   Upstream Author : Peter Hutterer 
> > * 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 (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)

[Daniel Gary]

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 (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)

[Russell Coker]

On Wed, 6 Apr 2011, Daniel Gary  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

[Russell Coker]

On Wed, 6 Apr 2011, Yaroslav Halchenko  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 (Re: Bug#620993: general: Lenny 2.6.26-2 has noticably increased swap usage, tho not swap thrashing)

[Daniel Gary]

On 4/5/2011 2:47 PM, Russell Coker wrote:

On Wed, 6 Apr 2011, Daniel Gary  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

[Peter Palfrader]

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?

[Ben Finney]

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 


signature.asc
Description: Digital signature

Processed: Re: Bug#620957: general: Would you be so kind to include Frandom in the Debian Repositories?

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 620957 wnpp
Bug #620957 {Done: Ben Hutchings } [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 } [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?]

[Carsten Hey]

* 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

[Paul Wise]

On Wed, Apr 6, 2011 at 1:14 AM, Margarita Manterola
 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)

[brian m. carlson]

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?]

[Luk Claes]

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!)

[Josselin Mouette]

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

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Josselin Mouette]

Le mardi 05 avril 2011 à 02:08 +0400, Stanislav Maslovski a écrit : 
> Well, that is not the question of how many, that is the question of
> can you do a given task or not with a given tool. NM is limited in all
> possible ways I can imagine, and also buggy. On the contrary, with
> ifupdown, one for sure can do things that I even cannot imagine due to
> my limited knowledge.

Your limited knowledge is like jam. The less you have, the more you
spread it.

What you actually like about ifupdown is that it cannot do anything but
extremely trivial setups. Then you can stack all soft of stuff on top of
it, and get them to work manually for your specific setup, and since
it’s not event-based you have to hard-code the way your network is set
up.

-- 
 .''`.  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

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Andrew O. Shadoura]

Hello,

On Wed, 06 Apr 2011 07:29:05 +0200
Josselin Mouette  wrote:

> Your limited knowledge is like jam. The less you have, the more you
> spread it.

Well, you have just confirmed this statement.

> What you actually like about ifupdown is that it cannot do anything
> but extremely trivial setups. Then you can stack all soft of stuff on
> top of it, and get them to work manually for your specific setup, and
> since it’s not event-based you have to hard-code the way your network
> is set up.

Maybe you just don't know how to 'cook' it properly?

-- 
WBR, Andrew


signature.asc
Description: PGP signature