Re: release update: Release goals, testing transition, arch requalification

[Peter Samuelson]

[Lionel Elie Mamane]
> > Ok, now to the approved release goals:
> > - full IPv6 support
> 
> What does that mean precisely? Drop all packages that don't support
> IPv6? IPv6 shall be enabled if supported not too buggily? Something
> in between? (I'm quite certain you don't mean drop all packages that
> don't support IPv6.)

Geez, I thought woody was supposed to fully support IPv6, except for a
few rough edges.  And that was how many years ago?  I think it is high
time to start talking about patching or dropping network apps that work
with IPv4 but not IPv6.  Of course, there will be a few apps that by
their nature don't make sense in IPv6, such as anything related to NAT
or the MBone, or whose functionality is provided quite differently in
IPv6, such as dhcpd, or clients that require specific non-free IPv4
servers, such as libnet-amazon-perl.  I suppose those can stay.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Steve Langasek]

On Wed, Aug 01, 2007 at 03:56:48PM -0300, Gustavo Franco wrote:
> On 8/1/07, Reinhard Tartler <[EMAIL PROTECTED]> wrote:
> > Neil Williams <[EMAIL PROTECTED]> writes:

> > (...)
> > > I tried the sample commands and apt wanted to add HALF A GIGABYTE of
> > > unnecessary stuff!!! Others may consider hard disc space cheap but, in
> > > truth, hard disc space is not infinite.

> > > Please, please, please, reconsider.

> > Please stop whining and start contributing. E.g. by filing bugs against
> > package (and possibly NMU them) that abuse the Recommends relationship.

> I would like to point out that pkg-gnome team already fixed the
> gnome-dbg related Recommends in svn; for those with
> gnome-desktop-environment installed if it was October 1st, it would
> install all the debug enabled packages. Lots of people using GNOME
> will see half a gigabyte results that will mean nothing once apt
> development team do the change they're planning.

Sorry, what do you mean to say here?  Are you claiming that having debug
packages in Recommends: is somehow a "fix"?  I'm quite sure that doesn't fit
the Policy definition of Recommends -- debugging applications is not at all
relevant to the common case, the common case should be that applications
don't need debugged. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Steve Langasek]

On Thu, Aug 02, 2007 at 09:44:04AM +0200, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Steve Langasek wrote:
> > Sorry, what do you mean to say here?  Are you claiming that having debug
> > packages in Recommends: is somehow a "fix"?  I'm quite sure that doesn't fit
> > the Policy definition of Recommends -- debugging applications is not at all
> > relevant to the common case, the common case should be that applications
> > don't need debugged. ;)

>  In March, Josselin made gnome depend on gnome-dbg and
>  gnome-desktop-environment recommend gnome-dbg in order to receive
>  meaningful backtraces from people running unstable or testing -- this
>  would have been reverted before the release.

>  Now, in SVN, gnome-desktop-environment only suggests gnome-dbg and
>  gnome only recommends it.  I suppose gnome won't recommend it in the
>  final stable release.

Hmm.  I would argue that gnome shouldn't recommend gnome-dbg either,
according to policy.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Stig Sandbeck Mathisen]

Neil Williams <[EMAIL PROTECTED]> writes:

> And a script to implement that in every box I have to install. Again
> and Again and Again and 

Puppet is > that way.  

If you have several machines, you may want to to handle them centrally
anyway, and this is a good reason to start.  You could begin with the
following in /etc/puppet/manifests/site.pp:



node default {
  include apt
}

class apt {

  file { "/etc/apt/sources.list":
source => "puppet://puppet.example.com/common/apt/sources.list",
notify => Exec["apt-get update"],
  }

  file { "/etc/apt/conf.d/install-recommends":
content => 'APT::Install-Recommends "true";',
notify => Exec["apt-get update"],
  }

  exec { "apt-get update":
command   => "/usr/bin/apt-get update",
refreshonly => true,
  }

}

If you have more than one distribution, sprinkle lightly with
variables and case statements.

> You almost forcing me into maintaining a fork of apt that restores
> the current behaviour from the very start.

You may find that using your energies elsewhere may be a bit more
rewarding in the long term.  :P

-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Julien BLACHE]

Sam Morris <[EMAIL PROTECTED]> wrote:

> The problem is that apt-get is *not* an advanced user tool. End users use 
> it because they see it referenced in all our documentation, all the 
> documentation they find elsewhere on the web and in our mailing list 
> archives, all the conversations they have on IRC while trying to find 
> help, etc...

Most (if not all) of the recent docs I've come to read mentionned
aptitude rather than apt-get.

If documentation is the only problem, then there's no problem.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Neil Williams <[EMAIL PROTECTED]> writes:

> The problem is that with packages like gnome-devel and gnome-core-devel
> (re: anjuta) >50% will require SOME of the Recommended packages. As a
> long term anjuta user, I would estimate that <5% of all users need ALL
> Recommended packages.

I've had exactly the same problem with one of my packages called
'libxine1'. Please compare the package relationships in Debian 'etch'
with the package relationships in Debian 'lenny'.

I splitted the off the ffmpeg output plugin in a different binary
package called 'libxine1-ffmpeg'. This makes it possible for you to
choose to not install the ffmpeg plugin at all, which wasn't possible
before. This means less crap you need to install. Usecases: buildds,
embedded systems.

> [...]
>
> Right problem. Wrong solution.

I'm curious to hear constructive suggestions from you. 

My understanding of constructive is not "Keep things as they are".

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpO9iqcHqJ2C.pgp
Description: PGP signature

Re: /bin/sh diversions

[Josselin Mouette]

Le mercredi 01 août 2007 à 14:18 -0700, Steve Langasek a écrit :
> On Wed, Aug 01, 2007 at 10:49:57PM +0200, Josselin Mouette wrote:
> > Le mercredi 01 août 2007 à 22:22 +0200, Wouter Verhelst a écrit :
> > > There are embedded environments where 80KB is a concern.
> 
> > I fail to see why you'd want to install any other shell than the
> > smallest one on such an environment.
> 
> Well, bash is essential, so you have to have that one installed or else you
> have to scan all your packages for uses of bash and convert them.

I guess the idea behind making dash the default /bin/sh is not only to
increase speed but also, in the end, to downgrade bash's priority.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

Re: Installation of Recommends by default on October 1st

[Peter Samuelson]

[Bernd Zeimetz]
> Especially with -dev packages I can't see a reason to 'recommend'
> another package - either you need foo-dev to be able to use bar-dev,
> or not. Developers usually know which libraries they want to use.

I disagree - I think Recommends is appropriate for a -dev package which
only needs another -dev package in the static linking case.  Or should
that be Suggests?  Currently I think most packagers use Depends here,
which I believe is too strong.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Steve Langasek wrote:
> Sorry, what do you mean to say here?  Are you claiming that having debug
> packages in Recommends: is somehow a "fix"?  I'm quite sure that doesn't fit
> the Policy definition of Recommends -- debugging applications is not at all
> relevant to the common case, the common case should be that applications
> don't need debugged. ;)

 In March, Josselin made gnome depend on gnome-dbg and
 gnome-desktop-environment recommend gnome-dbg in order to receive
 meaningful backtraces from people running unstable or testing -- this
 would have been reverted before the release.

 Now, in SVN, gnome-desktop-environment only suggests gnome-dbg and
 gnome only recommends it.  I suppose gnome won't recommend it in the
 final stable release.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

> apt-cache show openoffice.org-writer |grep Recom
> Recommends: openoffice.org-filter-binfilter, gij | java-gcj-compat | j2re1.4 
> | java2-runtime, openoffice.org-java-common (>> 2.2.0-4)
>
>   And really, I think this recommends like is perfectly correct, as many
> features in OOo are enabled if you have java installed.

[...]

> If I don't want to install java and the hundreds of megabytes it come
> with, how am I supposed to do ?

This question was rised (and answered) before:

http://article.gmane.org/gmane.linux.debian.devel.general/117707

Please reread the complete thread quoted above before answering this
post.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpUj5VNDlkPa.pgp
Description: PGP signature

Re: Prevent pdebuild from removing temporary build dir

[Andreas Tille]

On Wed, 1 Aug 2007, Pierre Habouzit wrote:


Sounds like what I'm looking for but I have problems to implement this
hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no visible
effect.  Did I missed something?


 it's used iff the build fails. So you have to make it fail...


Well - I think I have not to make anything if there is

...
../.libs/libvolpack.so: undefined reference to `VPCompAC1PB'
../.libs/libvolpack.so: undefined reference to `VPWarpA301N'
collect2: ld returned 1 exit status
make[3]: *** [classifyvolume] Error 1
make[3]: Leaving directory `/tmp/buildd/volpack-1.0b3/examples'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/tmp/buildd/volpack-1.0b3'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/buildd/volpack-1.0b3'
make: *** [debian/stamp-makefile-build] Error 2
pbuilder: Failed autobuilding of package
 -> Aborting with an error


I also tried to symlink  C10_launch_shell  to  B10_launch_shell  and
D10_launch_shell - just to make sure that I did not missed the point
of Paul.  To make clear what I'm talking about I uploaded the stuff
I'm working on to

   http://people.debian.org/~tille/packages/volpack/

As I said it works with debuild but not mit pdebuild and whatever
I try it does not trigger any hook (at my box).

Kind regards

Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Recommending -dbg packages

[Henrique de Moraes Holschuh]

On Thu, 02 Aug 2007, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Steve Langasek wrote:
> > Hmm.  I would argue that gnome shouldn't recommend gnome-dbg either,
> > according to policy.
> 
>  I'm disturbed by this too, but -- as I clarified on IRC -- I think
>  there's a conflict of interests between getting more meaningful
>  backtraces in average (and hence improving the quality of Debian before
>  the release / saving ourself a message to bug submitters) and
>  testing/sid users as first class users and hence respecting policy
>  during the full release cycle.  (My understanding is that the -dbg
>  recommend would have been dropped before the release.)

Well, IMHO if that information is really being useful (gather some data for
a while to make sure of it), then it is certainly something we can tolerate
in unstable and testing.  Produce some hard data, and we can even get it
into policy to explicitly allow for such, when there is an automated
crash-dump tool involved that sees heavy use by the users.

But I'd strongly suggest sending an email to debian-user and
debian-devel-announce explaining what is happening in quick, concise and
simple terms, so that we get less people being surprised by the massive -dbg
recommendation.  You probably want to copy debian-weekly-news, lwn.net and
maybe some other new sites that Debian unstable/testing users like on that
email, too.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Pierre Habouzit wrote:
>   *WTF* ? I mean why should I have every possible xserver video driver

 You also have all possible kernel drivers built by the kernel image
 installed; that's quite consistent with "any hardware you plugin will
 work".  The dep allows to pick one or more drivers if you so wish
 though.

 The only alternative I can think of is to propose the installation of
 the video driver when the hardware is detected; that's way harder to
 implement though.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Raphael Hertzog]

On Thu, 02 Aug 2007, Julien BLACHE wrote:
> Sam Morris <[EMAIL PROTECTED]> wrote:
> 
> > The problem is that apt-get is *not* an advanced user tool. End users use 
> > it because they see it referenced in all our documentation, all the 
> > documentation they find elsewhere on the web and in our mailing list 
> > archives, all the conversations they have on IRC while trying to find 
> > help, etc...
> 
> Most (if not all) of the recent docs I've come to read mentionned
> aptitude rather than apt-get.
> 
> If documentation is the only problem, then there's no problem.

I'm sorry but that's hardly the case. Google finds about 2 or 3 times more
reference to "Debian apt-get" than to "Debian aptitude".

Furthermore, it has already been said in this thread that it's confusing
to have two tools advertised by the project as being good to use that do
not follow policy in the same manner.

I definitely want Recommends installed by default given how easy it is for
advanced users to identify recommends that they don't wish to have. And
cleaning up the recommends to match policy is also a good thing to do.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Pierre Habouzit]

On Thu, Aug 02, 2007 at 02:19:41PM +1000, Anthony Towns wrote:
> On Wed, Aug 01, 2007 at 06:00:21PM +0200, Pierre Habouzit wrote:
> > On Wed, Aug 01, 2007 at 12:53:03PM -0300, Henrique de Moraes Holschuh wrote:
> > > OTOH, specifically using something else than /bin/sh for a fast
> > > POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but 
> > > dash
> > > is good) does NOT need /bin/sh to point to it, so it can't trip on such
> > > issues caused by external factors outside of Debian's control.
> >   Afaict ubuntu did the change, and the sky didn't fell apart.
> 
> It did cause a bunch of problems for Ubuntu users, though:
> 
> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463

  true, but like said, the most usual bashisms could be supported with
trivial patches to dash, when dash is invoked as /bin/sh (to not break
possible scripts using #!/bin/dash).

  the 3 biggest problems I've seen are:

  * [[ for test, trivial: add it as a test alias, and also check for ]]
termination in the test.c builtin.
  * echo -e: trivial to implement in the printf.c builtin.
  * { } globbing, dash uses the glibc's glob, so it's just a matter of
adding | GLOB_BRACE to the flags.

  Maybe source (for .) could be added to, I don't expect it to be much
harder. With that, you should be able to run most of the /bin/sh scripts
out there that were written with /bin/sh being bash.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpiPrZek2uKG.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Steve Langasek wrote:
> Hmm.  I would argue that gnome shouldn't recommend gnome-dbg either,
> according to policy.

 I'm disturbed by this too, but -- as I clarified on IRC -- I think
 there's a conflict of interests between getting more meaningful
 backtraces in average (and hence improving the quality of Debian before
 the release / saving ourself a message to bug submitters) and
 testing/sid users as first class users and hence respecting policy
 during the full release cycle.  (My understanding is that the -dbg
 recommend would have been dropped before the release.)

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Pierre Habouzit]

On Thu, Aug 02, 2007 at 09:45:35AM +0200, Reinhard Tartler wrote:
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
> 
> > apt-cache show openoffice.org-writer |grep Recom
> > Recommends: openoffice.org-filter-binfilter, gij | java-gcj-compat | 
> > j2re1.4 | java2-runtime, openoffice.org-java-common (>> 2.2.0-4)
> >
> >   And really, I think this recommends like is perfectly correct, as many
> > features in OOo are enabled if you have java installed.
> 
> [...]
> 
> > If I don't want to install java and the hundreds of megabytes it come
> > with, how am I supposed to do ?
> 
> This question was rised (and answered) before:
> 
> http://article.gmane.org/gmane.linux.debian.devel.general/117707
> 
> Please reread the complete thread quoted above before answering this
> post.

  This is not a solution, this is way more than impractical:

The following NEW packages will be installed:
  apache apache-common apache2-utils aptitude-doc-en aspell aspell-en
  avahi-daemon bsh-gcj cowdancer debconf-utils discover1 discover1-data
  docbook-dsssl docbook-utils docbook-xsl-doc-html dvipdfmx
  esound-clients fam fop gcc-multilib gimp-print gimp-svg gksu
  gnome-mount gutenprint-locales imagemagick jackd jadetex kamera
  kdemultimedia-kio-plugins kdiff3 ledit libadns1-bin libakode2
  libarts1-akode libasm-java libatk1.0-data libavahi-core5
  libavalon-framework-java libbatik-java libboost-regex1.34.0
  libbsf-java libcommons-io-java libcommons-logging-java
  libcompress-raw-zlib-perl libcompress-zlib-perl libdaemon0
  libdiscover1 libeel2-2.18 libeel2-data libenchant1c2a libfont-afm-perl
  libgail-common libgail18 libgcj-bc libgcj7-1 libgcj7-1-awt libgcj7-jar
  libgksu2-0 libglib2.0-data libgnome-menu2 libgnomevfs2-extra
  libgtop2-7 libgtop2-common libgutenprint2 libgutenprintui2-1
  libhtml-format-perl libio-compress-base-perl libio-compress-zlib-perl
  libipc-signal-perl libjaxp1.3-java-gcj libkcddb1 libmagick++9c2a
  libmime-types-perl libmudflap0 libmudflap0-4.2-dev
  libnautilus-extension1 libnss-mdns libosp5 libostyle1c2 libplot2c2
  libproc-waitstat-perl libpstoedit0c2a libsexy2 libsgmls-perl
  libtag1c2a libwmf-bin libwnck-common libwnck18 libxalan2-java-gcj
  libxerces2-java-gcj libxmlgraphics-commons-java lmodern mdetect menu
  mime-construct ncompress notification-daemon openjade p7zip-full
  perl-doc perl-suid perl-tk perlmagick preview-latex-style prosper
  psfontmgr pstoedit qjackctl sgmlspl source-highlight stgit tetex-bin
  tetex-extra texlive texlive-bibtex-extra texlive-font-utils
  texlive-fonts-extra texlive-generic-extra texlive-generic-recommended
  texlive-lang-croatian texlive-lang-cyrillic texlive-lang-czechslovak
  texlive-lang-danish texlive-lang-dutch texlive-lang-finnish
  texlive-lang-french texlive-lang-german texlive-lang-greek
  texlive-lang-hungarian texlive-lang-italian texlive-lang-latin
  texlive-lang-mongolian texlive-lang-norwegian texlive-lang-other
  texlive-lang-polish texlive-lang-portuguese texlive-lang-spanish
  texlive-lang-swedish texlive-lang-vietnamese texlive-latex-extra
  texlive-math-extra texlive-pictures texlive-pstricks
  texlive-publishers texpower texpower-manual tipa tla-doc videolan-doc
  wbritish x-ttcidfont-conf xresprobe xserver-xorg-video-all
  xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati
  xserver-xorg-video-chips xserver-xorg-video-cirrus
  xserver-xorg-video-cyrix xserver-xorg-video-dummy
  xserver-xorg-video-fbdev xserver-xorg-video-glint
  xserver-xorg-video-i128 xserver-xorg-video-mga
  xserver-xorg-video-neomagic xserver-xorg-video-nv
  xserver-xorg-video-rendition xserver-xorg-video-s3
  xserver-xorg-video-s3virge xserver-xorg-video-savage
  xserver-xorg-video-siliconmotion xserver-xorg-video-sis
  xserver-xorg-video-sisusb xserver-xorg-video-tdfx
  xserver-xorg-video-tga xserver-xorg-video-trident
  xserver-xorg-video-tseng xserver-xorg-video-v4l
  xserver-xorg-video-vesa xserver-xorg-video-vga xserver-xorg-video-via
  xserver-xorg-video-vmware xserver-xorg-video-voodoo zip zoo
0 upgraded, 186 newly installed, 0 to remove and 0 not upgraded.
Need to get 324MB of archives.
After unpacking 721MB of additional disk space will be used.
Do you want to continue [Y/n]?

  *WTF* ? I mean why should I have every possible xserver video driver
(I only need one), apache (and WTF does it recommends apache-doc ?!). Oh
and the whole texlive mess is also a nice touch.

  No, I just won't blacklist 186 packages in my /etc/apt/preferences,
this is just S wrong !



  PS: I'm very fond of the apache (to be removed) Recommends. really.
  especially on a notebook, it helps understanding how broken the
  recommends chain is right now.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp894xWvRw00.pgp
Description: PGP signature

Re: /bin/sh diversions

[Russ Allbery]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> I guess the idea behind making dash the default /bin/sh is not only to
> increase speed but also, in the end, to downgrade bash's priority.

I think that's going to be practically impossible.  Removing packages from
essential is a ton of work for what seems like fairly minimal gain.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Raphael Hertzog]

On Thu, 02 Aug 2007, Julien BLACHE wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> 
> >> Most (if not all) of the recent docs I've come to read mentionned
> >> aptitude rather than apt-get.
> >
> > I'm sorry but that's hardly the case. Google finds about 2 or 3 times more
> > reference to "Debian apt-get" than to "Debian aptitude".
> 
> Way to not read (or is that not understand ?) what I wrote :)
> 
> Hint: "recent".

I've read that but I didn't take it into account because people google for
docs and they will find documentation recommending apt-get (they usually won't
notice if the doc is recent or not). Furthermore, there's also the fact
that on user forums there are people who will still be recommending
apt-get as it's what they are using.

So you might be right on your first assertion, but I don't agree with your
conclusion "If doc is the only problem, then it's not a problem".

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Thijs Kinkhorst]

On Wednesday 1 August 2007 20:45, Reinhard Tartler wrote:
> Please stop whining and start contributing.

Neil already contributes a lot of work to Debian. Whether you agree with him 
or not, such an assertion is uncalled for and does not add to the discussion.


Thijs


pgpDqUBWXmenY.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Julien BLACHE]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

>> Most (if not all) of the recent docs I've come to read mentionned
>> aptitude rather than apt-get.
>
> I'm sorry but that's hardly the case. Google finds about 2 or 3 times more
> reference to "Debian apt-get" than to "Debian aptitude".

Way to not read (or is that not understand ?) what I wrote :)

Hint: "recent".

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Peter Samuelson]

[Pierre Habouzit]
>   the 3 biggest problems I've seen are:
> 
>   * [[ for test, trivial: add it as a test alias, and also check for ]]
> termination in the test.c builtin.

Ummm, [[ is not the same as [.  (If they were the same, there would
have been no need to invent [[.)  They behave quite differently with
regard to argument quoting.  Try this in bash:

  unset foo
  [ -n $foo ] && echo foo is non-empty
  [[ -n $foo ]] && echo foo is non-empty

As you can see, only the second one works.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Pierre Habouzit]

On Thu, Aug 02, 2007 at 10:20:42AM +0200, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Pierre Habouzit wrote:
> >   *WTF* ? I mean why should I have every possible xserver video driver
> 
>  You also have all possible kernel drivers built by the kernel image
>  installed; that's quite consistent with "any hardware you plugin will
>  work".  The dep allows to pick one or more drivers if you so wish
>  though.
> 
>  The only alternative I can think of is to propose the installation of
>  the video driver when the hardware is detected; that's way harder to
>  implement though.

  the point is I installed the proper driver myself. The recommends line
should be xserver-video-driver-all |  every driver |...

  So that it doesn't ask to install every driver each time. Actually the
xorg server does that using:

  xserver-video-driver-all | xserver-video-driver-1.0 and each
individual xserver-video-driver-foo provides the latter. So it seems
either --fix-policy --install-recommends does not what it's supposed to,
or apt is not clever enough yet to enable installation of recommends by
default.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgp7DQ9hZSRv5.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Julien BLACHE]

Raphael Hertzog <[EMAIL PROTECTED]> wrote:

> I've read that but I didn't take it into account because people google for
> docs and they will find documentation recommending apt-get (they usually won't
> notice if the doc is recent or not). Furthermore, there's also the fact
> that on user forums there are people who will still be recommending
> apt-get as it's what they are using.
>
> So you might be right on your first assertion, but I don't agree with your
> conclusion "If doc is the only problem, then it's not a problem".

When aptitude came out, we've been told that aptitude was the real apt
frontend that apt-get was never meant to be to begin with (apt-get
being only a debug/devel tool for libapt) and that it was the tool to
use from now on for everybody except maybe for advanced users who will
probably stick with apt-get.

Either this hasn't got enough publicity, or people decided to stick
with apt-get because aptitude didn't cut it.

The former case is easy enough to fix before October 1st; the latter
might not be that easy to fix, depending on the reasons behind the
dislike for aptitude.

Now, from the Debian users I know around me, I can tell you that none
of them like aptitude, and they especially dislike the "install
recommends by default" so-called "feature".

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Prevent pdebuild from removing temporary build dir

[Pierre Habouzit]

On Thu, Aug 02, 2007 at 10:24:41AM +0200, Andreas Tille wrote:
> On Wed, 1 Aug 2007, Pierre Habouzit wrote:
> 
> >>Sounds like what I'm looking for but I have problems to implement this
> >>hint.  I tried pdebuild --hookdir $HOME/.pbuilder and also added
> >>HOOKDIR=/home/myhome/.pbuilder to my .pbuilderrc but there is no 
> >>visible
> >>effect.  Did I missed something?
> >
> > it's used iff the build fails. So you have to make it fail...
> 
> Well - I think I have not to make anything if there is
> 
> 
> .../.libs/libvolpack.so: undefined reference to `VPCompAC1PB'
> .../.libs/libvolpack.so: undefined reference to `VPWarpA301N'
> collect2: ld returned 1 exit status
> make[3]: *** [classifyvolume] Error 1
> make[3]: Leaving directory `/tmp/buildd/volpack-1.0b3/examples'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/tmp/buildd/volpack-1.0b3'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/tmp/buildd/volpack-1.0b3'
> make: *** [debian/stamp-makefile-build] Error 2
> pbuilder: Failed autobuilding of package
>  -> Aborting with an error
> 
> 
> I also tried to symlink  C10_launch_shell  to  B10_launch_shell  and
> D10_launch_shell - just to make sure that I did not missed the point
> of Paul.  To make clear what I'm talking about I uploaded the stuff
> I'm working on to
> 
>http://people.debian.org/~tille/packages/volpack/
> 
> As I said it works with debuild but not mit pdebuild and whatever
> I try it does not trigger any hook (at my box).
> 
> Kind regards
> 
> Andreas.

  my pbuilder conf is online: http://madism.org/~madcoder/dotfiles/
don't forget to make the scripts +x...

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpY3yI68Hyjh.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Joey Schulze]

Loïc Minier wrote:
> On Wed, Aug 01, 2007, Marco d'Itri wrote:
> > > We, the APT Development Team, will change apt to install recommended
> > > packages by default on October 1st. This should give enough time to
> > Why? What is the point?
> 
>  Fix Recommends!  These are nothing more than Suggests right now --
>  except in aptitude.

And soon they become dependencies.  Shouldn't we then remove recommends
entirely and turn them into regular Depends?

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Pierre Habouzit <[EMAIL PROTECTED]> writes:

>> Please reread the complete thread quoted above before answering this
>> post.
>
>   This is not a solution, this is way more than impractical:

*sigh* (why do I write those disclaimers at all?)

In the thread above, I have proposed having a site specific blacklist
with package names, which should not be installed dispite being
recommended by another package. I also feel that pinning is too
cumbersome for this purpose.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


pgpoICVAWbsMM.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Julien BLACHE wrote:
> Now, from the Debian users I know around me, I can tell you that none
> of them like aptitude, and they especially dislike the "install
> recommends by default" so-called "feature".

 So what you're really battling against is enforcement of Recommends,
 not about enforcement of Recommends in a particular frontend, otherwise
 you would use aptitude.

 I think we should eat our dog food and fix Recommends to be useful
 again.  Just think of it as making some of the actual Recommends to
 Suggests and allowing back some of the actual Depends as Recommends.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Pierre Habouzit wrote:
>   the point is I installed the proper driver myself. The recommends line
> should be xserver-video-driver-all |  every driver |...

 And is it?

>   xserver-video-driver-all | xserver-video-driver-1.0 and each
> individual xserver-video-driver-foo provides the latter. So it seems
> either --fix-policy --install-recommends does not what it's supposed to,
> or apt is not clever enough yet to enable installation of recommends by
> default.

 If it is, it sounds like a bug in apt indeed, as the Recommends is
 already satisfied.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Reinhard Tartler]

Joey Schulze <[EMAIL PROTECTED]> writes:

> Shouldn't we then remove recommends entirely and turn them into
> regular Depends?

The sometime 'soft dependencies' called feature of Recommends and
Suggests is something which makes Debian unique compared to other
distributions. It would be sad to loose this.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Manoj Srivastava]

On Thu, 2 Aug 2007 10:17:03 +0200, Raphael Hertzog <[EMAIL PROTECTED]> said: 

> On Thu, 02 Aug 2007, Julien BLACHE wrote:
>> Sam Morris <[EMAIL PROTECTED]> wrote:
>> 
>> > The problem is that apt-get is *not* an advanced user tool. End
>> > users use it because they see it referenced in all our
>> > documentation, all the documentation they find elsewhere on the web
>> > and in our mailing list archives, all the conversations they have
>> > on IRC while trying to find help, etc...
>> 
>> Most (if not all) of the recent docs I've come to read mentionned
>> aptitude rather than apt-get.
>> 
>> If documentation is the only problem, then there's no problem.

> I'm sorry but that's hardly the case. Google finds about 2 or 3 times
> more reference to "Debian apt-get" than to "Debian aptitude".

Hmm. Perhaps we should either remove the APT Howto from our web
 site [0], or put in a reference there that apt-get is deprecated in
 favour of aptitude/synaptic?

manoj

0: http://www.debian.org/doc/manuals/apt-howto/

-- 
One picture is worth 128K words.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Thijs Kinkhorst wrote:
> Neil already contributes a lot of work to Debian. Whether you agree with him 
> or not, such an assertion is uncalled for and does not add to the discussion.

 I also witness that Neil (and you) did the best thing there is to do:
 filing bugs about bogus Recommends; yay!  \o/

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Julien BLACHE]

Loïc Minier <[EMAIL PROTECTED]> wrote:

>> Now, from the Debian users I know around me, I can tell you that none
>> of them like aptitude, and they especially dislike the "install
>> recommends by default" so-called "feature".
>
>  So what you're really battling against is enforcement of Recommends,
>  not about enforcement of Recommends in a particular frontend, otherwise
>  you would use aptitude.

I'd use aptitude if I wanted Recommends installed by default. I'm
using apt-get precisely because it's not doing this kind of stupid
things.

And I'd really like it if it could stay that way: use aptitude if you
want your Recommends installed by default, and leave apt-get alone for
the folks who like its current behaviour.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Thorsten Glaser]

Pierre Habouzit dixit:

>> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463

This is just clueless script writers and general whining; these
issues could be fixed one by one. (Actually, even with current
Debian policy, they're bugs.)

>  * [[ for test, trivial: add it as a test alias, and also check for ]]
>termination in the test.c builtin.

There's quite some difference though: -a and -o become && and ||,
\! doesn't work (operators have to be unquoted), the single-argument
form [ $foo ] is not supported (use [[ -n $foo ]]), variables are
not expanded, etc. - see http://www.mirbsd.org/man1/mksh.htm or the
AT&T ksh documentation ([[ is originally a Korn shell feature).

>  * echo -e: trivial to implement in the printf.c builtin.

People who still use echo in portable scripts should be shot anyway ☺☻
but this one is so common that I'd actually agree this could be supported.

>  * { } globbing, dash uses the glibc's glob, so it's just a matter of
>adding | GLOB_BRACE to the flags.

This csh-style globbing is enabled in some shells by "set -o braceexpand",
and some scripts (such as NetBSD's build.sh) explicitly turn it off; enab-
ling it by default could be dangerous (as they use "case $KSH_VERSION in…"
for checking if to disable it - who knows who else...).

>  Maybe source (for .) could be added

Where does that one come from anyway? I haven't seen it in Korn shell…

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: Installation of Recommends by default on October 1st

[Mike Hommey]

On Thu, Aug 02, 2007 at 10:01:22AM +0200, Pierre Habouzit <[EMAIL PROTECTED]> 
wrote:
>   PS: I'm very fond of the apache (to be removed) Recommends. really.
>   especially on a notebook, it helps understanding how broken the
>   recommends chain is right now.

I don't know for your case, but there are packages in debian that can use
apache as a file sharing backend. And it's particularly useful on laptops.

Now, the problem is we don't have any way, in these packages, to say that
they only need the binaries, and not the service running.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

intent to hijack gsasl

[Jorge Salamero Sanz]

hi,

the gsasl, libgsasl7 and libgsasl7-dev packages have not seen an upload since 
2006-03-16 [0].

there have been, however, several new upstream versions available which have 
been reported in the BTS [1].

this issue was raised again in -devel more than a month ago, ccing maintainer 
and sponsor [2] neither of both replied. in fact i had contacted them before 
without reply.
i'm really interesed in maintaining those packages, which are build-dep for 
jabberd2, where i'm currently working.

thus, i intent to hijack src:gsasl unless anyone gives me a good reason not to 
do so.

[0] http://packages.qa.debian.org/g/gsasl.html
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402156
[2] http://lists.debian.org/debian-devel/2007/06/msg00814.html

new packages:
http://bencer.cauterized.net/projects/debian/gsasl/


signature.asc
Description: This is a digitally signed message part.

Re: Installation of Recommends by default on October 1st

[Manuel Prinz]

Russ Allbery wrote:
> I think it's also particularly annoying for our two major recommended
> package installation interfaces, aptitude and apt-get, to do the opposite
> thing by default with this core of a feature.  What a recipe for
> confusion for the average user who doesn't know the history and doesn't
> choose them based on their Recommends-handling behavior!  We shouldn't be
> substituting tool selection for configuration.

Exactly. One thing I quite often experienced by introducing people to
Debian is that they get all confused about the different behaviors of
apt-get and aptitude. To most users, those tools are a way to install
packages, and not knowing their history leads to confusing why they do
the same task in different ways.

Most of those are totally fine with installing "junk", as it was called
by others on this thread. They like it because having all x-drivers on
their system allows them to exchange graphic cards without much effort.
It's done rarely, I know. But most of them are unexperienced users of
either Debian or Linux and want things to "just work" which is the
Debian way. And the Social Contract is about our users, and I think an
identical behaviour in the apt tools and having Recommends is what the
majority of users want.

I use aptitude for my everyday work. On my desktop, I really appreciate
pulling in Recommends. On cluster compute nodes, I don't. But I can turn
it of easily without being "forced" to use apt-get just because I'm on a
different type of machine. Compute nodes are what I'd call an "unusual
installation", as the Policy states it for Recommends. So are Embedded
Devices. (Of course, the definition of "usual" is always vague.)

IMHO, having apt-get to install recommended packages is a good choice.
It's not hard for the user with special needs to change it, even on a
lot of boxes. It's the current Recommends: fields that are broken, not
the tools. But IANADD.

Best regards
Manuel



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Prevent pdebuild from removing temporary build dir

[Andreas Tille]

On Thu, 2 Aug 2007, Pierre Habouzit wrote:


 my pbuilder conf is online: http://madism.org/~madcoder/dotfiles/


Well, thanks for this in general because I learned some more than
I hoped for in general.


don't forget to make the scripts +x...


I did so before.  I even added a "touch /tmp/pbuilder_`basename $0`"
to the scripts ... but no /tmp/pbuilder* occured in my /tmp - so they
are just not called.

Any further hint?

Kind regards

  Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Prevent pdebuild from removing temporary build dir

[Ian Campbell]

On Thu, 2007-08-02 at 14:22 +0200, Andreas Tille wrote:
> Any further hint?

As a workaround you could use "pbuilder login", manually pull in the
build deps and run debuild etc.

Perhaps a wishlist bug on pbuilder would be appropriate since keeping
the build dir would indeed be useful.

Ian.

-- 
Ian Campbell
Current Noise: Andensum - Just Another Reason

This dungeon is owned and operated by Frobozz Magic Co., Ltd.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Luca Capello]

Hello!

On Thu, 02 Aug 2007 11:38:06 +0200, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Pierre Habouzit wrote:
>>   xserver-video-driver-all | xserver-video-driver-1.0 and each
>> individual xserver-video-driver-foo provides the latter. So it
>> seems either --fix-policy --install-recommends does not what it's
>> supposed to, or apt is not clever enough yet to enable installation
>> of recommends by default.
>
>  If it is, it sounds like a bug in apt indeed, as the Recommends is
>  already satisfied.

AFAIK (and if I'm correct in my analysis) it is, but probably in how
apt-get resolves the dependencies.  I hadn't reported it because I
tried to debug it but I couldn't find the correct debug option.  Thus
reported now as bug #435662 [1].

BTW and FYI, the same bug is also present in aptitude :-(

Thx, bye,
Gismo / Luca

Footnotes: 
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435662


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Michael Tautschnig]

[...]
> I use aptitude for my everyday work. On my desktop, I really appreciate
> pulling in Recommends. On cluster compute nodes, I don't. But I can turn
> it of easily without being "forced" to use apt-get just because I'm on a
> different type of machine. Compute nodes are what I'd call an "unusual
> installation", as the Policy states it for Recommends. So are Embedded
> Devices. (Of course, the definition of "usual" is always vague.)
[...]

Please consider two things:
- More than 90% of all processors are installed in embedded systems (of course,
  only on pretty few of them Debian is installed)
- (Debian) Linux is still more widely spread on server systems than on Desktops
  ([1,2] sorry, both are German)

However, especially Desktop users must be handled with extra care, so probably
staying with the current state really isn't an option. What I'd propose is not a
debconf question by apt, but rather the debian-installer. I'd follow this
approach for three reasons:
- debconf is used by the d-i anyway already, so no need for the APT-people to
  add debconf-stuff
- the d-i may be pre-seeded, so auto-installs using the d-i may avoid 
displaying 
  this question
- In case someone doesn't use d-i to setup systems there will be ways to modify
  the apt configuration anyway (be it copying or editing of config files or
  whatever)

What remains to be discussed is then, whether already installed systems should
get recommended packages or not. To go a little further, what would be a proper
way of asking users whether they want their settings changed or not (apart from
apt asking debconf questions).

Best,
Michael

[1] http://www.linux-professionell.net/praxis/article20061110018.aspx
[2] http://derstandard.at/?url=/?id=2974144



pgpdRVF4VRL9Q.pgp
Description: PGP signature

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Julien BLACHE wrote:
> I'd use aptitude if I wanted Recommends installed by default. I'm
> using apt-get precisely because it's not doing this kind of stupid
> things.

 Well, now you're going to use aptitude to not install recommends by
 default!
alias aptitude='aptitude -R'

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Wouter Verhelst]

On Wed, Aug 01, 2007 at 11:30:33PM +0100, Neil Williams wrote:
> Recommends: is easy with small packages, it becomes more difficult when
> each user does different things with the one package.

This is nothing more than an interface problem. For instance, I think
aptitude should make it more obvious in its preview that a particular
package is being pulled in as a recommends rather than a depends.
Currently they're all thrown in the same bunch as "These are installed
because something else wants them", which is not very helpful.

[...]
> Policy does not mandate that ALL Recommends: are to be installed. The
> new default makes Recommends: disappear completely - there would be no
> difference between Depends: and Recommends: just like there is a
> perception of no real difference between Recommends: and Suggests: at
> the moment. That makes things HARDER for people like me who do not want
> Recommends: because maintainers will lose any reason to put things in
> Recommends: and will end up putting everything in Depends: just as many
> current Recommends: are actually just Suggests:
> 
> The blanket default that does not take the real meaning of Policy.

The real meaning of policy is what's being implemented currently.

The fact that apt hasn't done this for years is a bug, and this has lead
to many many many more bugs in other packages who considered Recommends
to be a strong Suggests rather than a weak Depends, since that's how apt
implemented it. These packages should be fixed; bugs should be filed on
them. It would also be nice if it were possible to get aptitude to be
more verbose, as I said above, I guess.

Other than that, at least apt will not pull a dselect on you. I really
don't see your problem.

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Magnus Holmgren]

On Thursday 02 August 2007 12:01, Julien BLACHE wrote:
> I'd use aptitude if I wanted Recommends installed by default. I'm
> using apt-get precisely because it's not doing this kind of stupid
> things.

I use aptitude and I don't want Recommends to be installed by default. This is 
not Windows. Here you can configure your software the way you want it.

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)


pgpTwiADkSS75.pgp
Description: PGP signature

Re: adding desktop files to misc packages

[Bill Allombert]

On Mon, Jul 16, 2007 at 12:40:28PM +0200, Raphael Hertzog wrote:
> Bill, you haven't participated in this discussion, what's your opinion?
> Would you like to do that work?

I stated my opinion an hundred time already, here a quick summary:

1) There is a place for two menu structure in Debian: an omnibus one
(Debian menu) and a Desktop-oriented one (XDG menu) where only 
desktop relevant apps would be mentioned.

2) The XDG menu entries suffers from lack of clear policy about what
software should go in the menu and in which categories.
For example should asciijump provide a .desktop file ? xdvi ? gv ?
lilo ? etc.

3) The XDG menu entries suffers from general lack on maintainance.  A
lot of upstream-provided ".desktop" files outside native KDE/GNOME
packages are wrong, and never fixed. At the very least compliance with
the standard should be checked. 

4) Bugs with Debian menu under GNOME were actually bugs in the XDG menu
implementation in GNOME. The KDE implementation was much better. Blaming
Debian menu for them is unfair. 

5) There are dozen of ways to not display the Debian menu under GNOME.
What is lacking is an easy interface beside "do not install menu".
Maybe the d-i team could propose an interface and I will see how it
can be implemented.

> Would it be helpful to have the technical committee decide on this
> topic?

It would not. Instead please write a policy about what softwares
are worthy to appear in the XDG menu and get it accepted by the
debian-desktop participants, and start to report bugs.

I am not interested in maintaining the XDG menu myself. I do not use 
desktop environment. I am interested to maintain Debian menu, however.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Petter Reinholdtsen]

[Josselin Mouette]
> I guess the idea behind making dash the default /bin/sh is not only to
> increase speed but also, in the end, to downgrade bash's priority.

As the one proposing it as a release goal, I can confirm that this is
not the case.  The only idea behind it for me is to increase speed.

If others want to downgrade the priority of bash, I wish them luck and
hope they see it as a completely different effort from the work done
to speed up the distribution. :)

Happy hacking,
-- 
Petter Reinholdtsen


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Marco d'Itri]

On Aug 02, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> I guess the idea behind making dash the default /bin/sh is not only to
> increase speed but also, in the end, to downgrade bash's priority.
I don't think so.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Installation of Recommends by default on October 1st

[Manuel Prinz]

Michael Tautschnig wrote:
> Please consider two things:
> - More than 90% of all processors are installed in embedded systems (of 
> course,
>   only on pretty few of them Debian is installed)
> - (Debian) Linux is still more widely spread on server systems than on 
> Desktops
>   ([1,2] sorry, both are German)

Thanks for the links, it was an interesting read! I was aware of the
fact that Embedded Devices have to be taken into account, was well as
servers and other non-desktop boxes. I don't want to ignore them but I
think it's users are skilled enough to deal with the issue.

> However, especially Desktop users must be handled with extra care, so probably
> staying with the current state really isn't an option. What I'd propose is 
> not a
> debconf question by apt, but rather the debian-installer. I'd follow this
> approach for three reasons:
> - debconf is used by the d-i anyway already, so no need for the APT-people to
>   add debconf-stuff
> - the d-i may be pre-seeded, so auto-installs using the d-i may avoid 
> displaying 
>   this question
> - In case someone doesn't use d-i to setup systems there will be ways to 
> modify
>   the apt configuration anyway (be it copying or editing of config files or
>   whatever)
> 
> What remains to be discussed is then, whether already installed systems should
> get recommended packages or not. To go a little further, what would be a 
> proper
> way of asking users whether they want their settings changed or not (apart 
> from
> apt asking debconf questions).

I agree with you here. I think that new installations aren't affected
much because there are possibilities to work around the "problem"
easily, as you have shown above. So the real problem is in the current
transition. I would not like a debconf from apt either but can't really
come up with a better solution. The only thing that comes into my mind
to use a wrapper for apt-get that checks if APT::Install-Recommends
being set in the preferences and prints a warning that the default
behavior has changed and pointing to some document that describes the
changes. Hope someone has a smarter idea. :)

Best regards
Manuel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: adding desktop files to misc packages

[Bill Allombert]

On Mon, Jul 16, 2007 at 08:07:05PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Mon, Jul 16, 2007 at 04:12:02AM -0700, Don Armstrong wrote:
> > So it seems like we should do the following:
> (...)
> 
> 4. Add i18n support to menu so that it can generate localised menu names,
>entries and tooltips both when converting desktop -> menu (for WM !=
>KDE/GNOME/Xfce) and when converting menu -> desktop (for WM ==
>KDE/GNOME/Xfce). As WM might not have i18n support for their menu, this
>should be based on the system's /etc/default/locale setting when
>converting from desktop -> menu to select a single text string there.

As hinted in my d-d-a post, lenny menu will provide full translations
of the menu under the condition that the translatable strings (title
and longtitle) reach an acceptable quality level. We are working on
it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

needs=vc as menu field useful and needed?

[Nico Golde]

Hi,
I recently stumbled upon the needs="vc" field for debian menu 
files.

The menu manual says the following about them:

 3.   `vc': if it runs under a linux virtual console but not under a X
  terminal emulator.

Currently we have 27 _programs_ using this special field. I asked myself why
a user wants to have a program that can't run under no circumstances under X
in a menu under X.

The packages using needs=vc with debtags information:

aatv:  Tag: game::toys, hardware::video, implemented-in::c, 
interface::commandline, interface::text-mode, role::program, scope::utility, 
use::viewing, works-with::video
apple2:Tag: hardware::emulation
aumix-gtk: Tag: implemented-in::c, interface::x11, role::program, 
scope::utility, sound::mixer, uitoolkit::gtk, uitoolkit::ncurses, 
works-with::audio, x11::application
bsdgames:  not tagged
c3270: Tag: uitoolkit::ncurses
cadubi:Tag: use::editing
chdrv: Tag: culture::chinese, culture::taiwanese
cthugha:   Tag: sound::player, uitoolkit::athena, uitoolkit::ncurses
dvifb: Tag: interface::framebuffer, role::program, scope::utility, 
use::viewing, works-with::text, works-with-format::dvi
dvisvga:   Tag: interface::svga, role::program, scope::utility, 
use::viewing, works-with::text, works-with-format::dvi
fbtv:  Tag: interface::framebuffer, role::program, scope::utility, 
uitoolkit::ncurses, use::viewing, works-with::video
fte-console:   not tagged
heroes-ggi:Tag: game::arcade, interface::x11, role::program, 
use::gameplaying, x11::application
heroes-sdl:Tag: game::arcade, interface::x11, role::program, 
uitoolkit::sdl, use::gameplaying, x11::application
libggi-samples:Tag: devel::examples, devel::library, interface::x11, 
role::program, scope::utility, uitoolkit::ncurses, x11::library
luxman:Tag: game::arcade, interface::svga, interface::x11, 
role::program, use::gameplaying, x11::application
lxdoom-svga:   Tag: game::arcade, interface::3d, role::program, use::gameplaying
pinball:   Tag: game::simulation, implemented-in::c++, interface::x11, 
role::program, uitoolkit::ncurses, uitoolkit::sdl, use::gameplaying, 
x11::application
prboom:Tag: game::arcade, interface::3d, role::program, uitoolkit::sdl, 
use::gameplaying, x11::application
psmisc:Tag: interface::text-mode, role::program, scope::utility, 
uitoolkit::ncurses, works-with::software:running
sabre: Tag: game::arcade, interface::3d, interface::x11, role::program, 
uitoolkit::ncurses, use::gameplaying, x11::application
scheme48:  not tagged
svncviewer:Tag: interface::svga, network::client, role::program, 
use::login, use::viewing
synaesthesia:  Tag: game::demos, interface::x11, sound::player, uitoolkit::sdl, 
use::viewing, works-with::audio, x11::application
thrust:Tag: game::arcade, interface::svga, junior::arcade, 
role::program, use::gameplaying

When looking at the tags it doesn't look like the programs can't run in an X
terminal. I tried worms from bsdgames, cadubi and pinball (randomly picked) and 
they all
worked flawless in my aterm.

So even if I missed some packages that really don't run under X, what's the 
purpose
of having them in the user menu and is there really still a need for needs="vc"?
Should it be removed? Opinions, do I miss something?

Kind regards
Nico

-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpgoIBEoZFgD.pgp
Description: PGP signature

Bug#435678: ITP: cheese -- take pictures and videos from your webcam

[Franz Pletz]

Package: wnpp
Severity: wishlist
Owner: Franz Pletz <[EMAIL PROTECTED]>

* Package name: cheese
  Version : 0.1.4
  Upstream Author : Daniel G. Siegel <[EMAIL PROTECTED]>
* URL : http://live.gnome.org/Cheese
* License : GPL-2
  Programming Lang: C
  Description : take pictures and videos from your webcam

 Photobooth-inspired GNOME application for taking pictures and videos
 from a webcam. It also includes fancy graphical effects based on the
 gstreamer-backend.
 .
 Future releases will be able to interface with IM clients, youtube and
 flickr.
  


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Guillem Jover]

Hi,

On Thu, 2007-08-02 at 11:04:14 +0200, Pierre Habouzit wrote:
>   So that it doesn't ask to install every driver each time. Actually the
> xorg server does that using:
> 
>   xserver-video-driver-all | xserver-video-driver-1.0 and each
> individual xserver-video-driver-foo provides the latter. So it seems
> either --fix-policy --install-recommends does not what it's supposed to,
> or apt is not clever enough yet to enable installation of recommends by
> default.

I think you (and some others on this thread) might want to reread the
announcement mail:

,
| Apt will install recommends by default for new packages as if those
| were depends.  But it will not complain about unsatisfied recommends
| on your system.
|
| [...]
|
| Because it only affects new package installs on your currently
| installed packages nothing changes. If you want to see what would
| change if you had a system with --install-recommends please run:
|
| # apt-get install --fix-policy --install-recommends
`

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: needs=vc as menu field useful and needed?

[Wouter Verhelst]

On Thu, Aug 02, 2007 at 04:12:20PM +0200, Nico Golde wrote:
> Hi,
> I recently stumbled upon the needs="vc" field for debian menu 
> files.
> 
> The menu manual says the following about them:
> 
>  3.   `vc': if it runs under a linux virtual console but not under a X
>   terminal emulator.
> 
> Currently we have 27 _programs_ using this special field. I asked myself why
> a user wants to have a program that can't run under no circumstances under X
> in a menu under X.

Try installing pdmenu

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: needs=vc as menu field useful and needed?

[Nico Golde]

Hi,
* Wouter Verhelst <[EMAIL PROTECTED]> [2007-08-02 16:58]:
> On Thu, Aug 02, 2007 at 04:12:20PM +0200, Nico Golde wrote:
> > Hi,
> > I recently stumbled upon the needs="vc" field for debian menu 
> > files.
> > 
> > The menu manual says the following about them:
> > 
> >  3.   `vc': if it runs under a linux virtual console but not under a X
> >   terminal emulator.
> > 
> > Currently we have 27 _programs_ using this special field. I asked myself why
> > a user wants to have a program that can't run under no circumstances under X
> > in a menu under X.
> 
> Try installing pdmenu

Ok but then I would consider it a bug at least in the 
progams I tried to use this field.
Kind regards
Nico
-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgprNpWC6WX5W.pgp
Description: PGP signature

Re: needs=vc as menu field useful and needed?

[Guillem Jover]

On Thu, 2007-08-02 at 16:12:20 +0200, Nico Golde wrote:
> When looking at the tags it doesn't look like the programs can't run
> in an X terminal. I tried worms from bsdgames, cadubi and pinball
> (randomly picked) and they all worked flawless in my aterm.

Programs using the framebuffer directly, or svgalib for example don't
work under X.

regards,
guillem


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Don Armstrong]

On Thu, 02 Aug 2007, Thorsten Glaser wrote:
> Pierre Habouzit dixit:
> 
> >> https://bugs.launchpad.net/ubuntu/+source/dash/+bug/61463
> 
> This is just clueless script writers and general whining; these
> issues could be fixed one by one. (Actually, even with current
> Debian policy, they're bugs.)

They are bugs when present in Debian packages, but not necessarily
bugs when present in user's scripts. Changing what /bin/sh is on new
systems is one thing; changing out from under users on existing
systems is another.

I personally don't particularly care if we switch the default, so long
as it's well publicised and the steps necessary to switch back if
there are problems and/or to test if there are going to be problems
with important user scripts before you upgrade.


Don Armstrong

-- 
"I was thinking seven figures," he said, "but I would have taken a
hundred grand. I'm not a greedy person." [All for a moldy bottle of
tropicana.]
 -- Sammi Hadzovic [in Andy Newman's 2003/02/14 NYT article.]
 http://www.nytimes.com/2003/02/14/nyregion/14EYEB.html

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Don Armstrong]

On Thu, 02 Aug 2007, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Steve Langasek wrote:
> > Hmm.  I would argue that gnome shouldn't recommend gnome-dbg either,
> > according to policy.
> 
>  I'm disturbed by this too, but -- as I clarified on IRC -- I think
>  there's a conflict of interests between getting more meaningful
>  backtraces in average (and hence improving the quality of Debian before
>  the release / saving ourself a message to bug submitters) and
>  testing/sid users as first class users and hence respecting policy
>  during the full release cycle.  (My understanding is that the -dbg
>  recommend would have been dropped before the release.)

Is there any reason why this isn't handled by a
/usr/share/bug/gnome/script (or whatever is appropriate) which tells
the user to install the -dbg package if they aren't currently
installed so backtraces can be generated?

Once you've got the corefile, you can always mate the -dbg to it after
the fact.


Don Armstrong

-- 
"Ban cryptography! Yes. Let's also ban pencils, pens and paper, since
criminals can use them to draw plans of the joint they are casing or
even, god forbid, create one time pads to pass uncrackable codes to
each other. Ban open spaces since criminals could use them to converse
with each other out of earshot of the police. Let's ban flags since
they could be used to pass secret messages in semaphore. In fact let's
just ban all forms of verbal and non-verbal communication -- let's see
those criminals make plans now!"

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: Installation of Recommends by default on October 1st

[Joey Schulze]

Reinhard Tartler wrote:
> Joey Schulze <[EMAIL PROTECTED]> writes:
> 
> > Shouldn't we then remove recommends entirely and turn them into
> > regular Depends?
> 
> The sometime 'soft dependencies' called feature of Recommends and
> Suggests is something which makes Debian unique compared to other
> distributions. It would be sad to loose this.

Don't we lose it already on October 1st when apt-get installs all
Recommends per default?  It's ok for high-level tools like aptitude
and Synaptic to behave that way, but I'm not exactly happy for
apt-get to go that way.

At the moment, we who have read Michael's announcement, know how to
get the old behaviour back (althouth apt-get complained about the
line he provided), but soon nobody will remember.  Then I wonder if
this feature you praise is lost.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#435693: ITP: qca2-plugin-ossl -- OpenSSL plugin for QCA2

[Jan Niehusmann]

Package: wnpp
Severity: wishlist
Owner: Jan Niehusmann <[EMAIL PROTECTED]>


* Package name: qca2-plugin-ossl
  Version : 0.1~20070706
  Upstream Author : Justin Karneges <[EMAIL PROTECTED]>, Brad Hards <[EMAIL 
PROTECTED]>
* URL : http://delta.affinix.com/qca/
http://delta.affinix.com/download/qca/2.0/beta7/
* License : LGPL
  Programming Lang: C++
  Description : OpenSSL plugin for QCA2

 This plugin provides features based on OpenSSL. It implements:
  * Hashing - SHA1, SHA0, RIPEMD160, MD2, MD4, MD5
  * Hashing - SHA224, SHA256, SHA384 and SHA512 (for openssl 0.9.8)
  * Block Ciphers
  * Keyed Hash Message Authentication Code (HMAC), using SHA1, MD5, RIPEMD160
  * Public keys - RSA, DSA, Diffie-Hellman
  * PKCS#12
  * SSL/TLS
  * CMS (for S/MIME)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Don Armstrong wrote:
> Is there any reason why this isn't handled by a
> /usr/share/bug/gnome/script (or whatever is appropriate) which tells
> the user to install the -dbg package if they aren't currently
> installed so backtraces can be generated?

 While this is an interesting suggestion (which I'm taking note of!),
 it might not be enough when users are using specific reporting tools:
 bug-buddy comes to mind for example.

> Once you've got the corefile, you can always mate the -dbg to it after
> the fact.

 Hmm I don't expect the majority of users to know how to do this nor how
 to enable core dumps in the default config.


 This very discussion reminds me that we lack a serious debugging
 infrastructure like major projects or companies have: Mozilla, Ubuntu,
 Apple, Microsoft...  We really need new tools:
 - to collect segfault data using a different channel than bug reports
   (for example to merge multiple reports into one, to find top
   crashers, to protect sensitive information, ...)
 - to get crashes with useful information (propose installing -dbg
   packages, collect crash specific information such as
   ~/.xsession-errors for desktop apps)
 - etc.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Don Armstrong]

On Thu, 02 Aug 2007, Joey Schulze wrote:
> Don't we lose it already on October 1st when apt-get installs all
> Recommends per default? It's ok for high-level tools like aptitude
> and Synaptic to behave that way, but I'm not exactly happy for
> apt-get to go that way.

The entire point of Recommends is so that you don't have to have
pacakges that may not be required in unusual situtations installed
without doing equivs machinations or similar tricks to avoid them.

The ability to degrade things that are almost Depends: to a "installed
by default, but can be removed or otherwise configured" state is far
superior to an on-off state.

> At the moment, we who have read Michael's announcement, know how to
> get the old behaviour back (althouth apt-get complained about the
> line he provided), but soon nobody will remember. Then I wonder if
> this feature you praise is lost.

If no one is able to remember, they should look at the documentation.
Frankly, if they aren't capable of reading the documentation, then
they probably aren't able to determine whether they actually do or do
not need the Recommends. [If you're arguing that this is somehow a
slipery slope and the next step is is a Recommends are Depends
tautology, I don't know how to argue with you, besides saying that
many people (which probably includes the current apt mantainers) would
revert such a slide were it to occur.]


Don Armstrong

-- 
A Bill of Rights that means what the majority wants it to mean is worthless. 
 -- U.S. Supreme Court Justice Antonin Scalia

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Cameron Dale]

On 8/2/07, Julien BLACHE <[EMAIL PROTECTED]> wrote:
> Raphael Hertzog <[EMAIL PROTECTED]> wrote:
>
> >> Most (if not all) of the recent docs I've come to read mentionned
> >> aptitude rather than apt-get.
> >
> > I'm sorry but that's hardly the case. Google finds about 2 or 3 times more
> > reference to "Debian apt-get" than to "Debian aptitude".
>
> Way to not read (or is that not understand ?) what I wrote :)
>
> Hint: "recent".

I just searched on the Ubuntu forums (a place full of "regular", i.e.
not advanced, users) and found these results for Yesterday, which I
hope is recent enough. :)

threads mentioning apt-get: 146
threads mentioning aptitude: 27

posts mentioning apt-get: 214
posts mentioning aptitude: 34

I don't think there's any doubt from this that most people
use/recommend apt-get, even among the "regular" users.

Cameron


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: needs=vc as menu field useful and needed?

[Joey Hess]

Nico Golde wrote:
> dvisvga:   Tag: interface::svga, role::program, scope::utility, 
> use::viewing, works-with::text, works-with-format::dvi
> luxman:Tag: game::arcade, interface::svga, interface::x11, 
> role::program, use::gameplaying, x11::application
> lxdoom-svga:   Tag: game::arcade, interface::3d, role::program, 
> use::gameplaying
> svncviewer:Tag: interface::svga, network::client, role::program, 
> use::login, use::viewing
> thrust:Tag: game::arcade, interface::svga, junior::arcade, 
> role::program, use::gameplaying

These at least clearly use svgalib.

> When looking at the tags it doesn't look like the programs can't run in an X
> terminal. I tried worms from bsdgames, cadubi and pinball (randomly picked) 
> and they all
> worked flawless in my aterm.

I may have had a reason to make worms needs=vc. IIRC it locks up certian
dumb terminals due to spewing so much data at the terminal. However my
reasons for doing it has been lost in the mists of 1995 and I reverted
it.

A lintian test for needs=vc programs that are not linked with svgalib
or directfb would be nice.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Oleg Verych]

02-08-2007, Peter Samuelson:
>
> [Pierre Habouzit]
>>   the 3 biggest problems I've seen are:
>>=20
>>   * [[ for test, trivial: add it as a test alias, and also check for ]]
>> termination in the test.c builtin.
>
> Ummm, [[ is not the same as [.  (If they were the same, there would
> have been no need to invent [[.)  They behave quite differently with
> regard to argument quoting.  Try this in bash:
>
>   unset foo
>   [ -n $foo ] && echo foo is non-empty
>   [[ -n $foo ]] && echo foo is non-empty
>
> As you can see, only the second one works.

Not quoting possible empty argument is a script writing bug. It's like
dereferencing NULL pointer and must be shot away also. Supporting
buggy scripting by inventing new tools is struggling with consequences
not cause and is a very bad idea.

BTW, i've provided patch in the BTS for dash's test built-in to have
arithmetic checking of an empty argument and zero right. This was nearly
a month ago, yet nothing happened. (Flaming about dash is easy,
maintaining is not :)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Don Armstrong]

On Thu, 02 Aug 2007, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Don Armstrong wrote:
> > Is there any reason why this isn't handled by a
> > /usr/share/bug/gnome/script (or whatever is appropriate) which
> > tells the user to install the -dbg package if they aren't
> > currently installed so backtraces can be generated?
> 
>  While this is an interesting suggestion (which I'm taking note
>  of!), it might not be enough when users are using specific
>  reporting tools: bug-buddy comes to mind for example.

This should probably be fixed then if bug-buddy is recommended by
gnome (or used for reporting bugs against things that aren't in the
gnome bugzilla.)

> > Once you've got the corefile, you can always mate the -dbg to it
> > after the fact.
> 
>  Hmm I don't expect the majority of users to know how to do this nor
>  how to enable core dumps in the default config.

If they don't enable core dumps in the default config, the backtraces
aren't going to be terribly useful (or may not even exist), right?
Then the -dbg packages aren't going to help much either.
 

Don Armstrong

-- 
My spelling ability, or rather the lack thereof, is one of the wonders
of the modern world.

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: Installation of Recommends by default on October 1st

[Oleg Verych]

02-08-2007, LoОc Minier:
> On Thu, Aug 02, 2007, Pierre Habouzit wrote:
>>   *WTF* ? I mean why should I have every possible xserver video driver
>
>  You also have all possible kernel drivers built by the kernel image
>  installed; that's quite consistent with "any hardware you plugin will
>  work".  The dep allows to pick one or more drivers if you so wish
>  though.

There was a laptop mentioned, btw: no pci hotplug, infiniband, isdn, scsi
and A lot more.

Problem is solved, if you didn't noticed already.  All that bunch of
modules can be easily removed before installation. My laptop and all
devices i have or suppose to have let me clean up nearly 58M of
linux-image.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Oleg Verych]

02-08-2007, Mike Hommey:
> On Thu, Aug 02, 2007 at 10:01:22AM +0200, Pierre Habouzit <[EMAIL PROTECTED]> 
> wrote:
>>   PS: I'm very fond of the apache (to be removed) Recommends. really.
>>   especially on a notebook, it helps understanding how broken the
>>   recommends chain is right now.
>
> I don't know for your case, but there are packages in debian that can use
> apache as a file sharing backend. And it's particularly useful on laptops.

_file_ sharing; another web-like crap?

The FTP, despite of not being able to follow symlinks, what is the
problem? That is easily solved by making /home/ftp a symlink to your
big-file storage.

I use pure-ftp for sharing. mc, any-web-browser or lftp are OK as
clients.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Joey Hess]

Loïc Minier wrote:
>  I'm disturbed by this too, but -- as I clarified on IRC -- I think
>  there's a conflict of interests between getting more meaningful
>  backtraces in average (and hence improving the quality of Debian before
>  the release / saving ourself a message to bug submitters) and
>  testing/sid users as first class users and hence respecting policy
>  during the full release cycle.  (My understanding is that the -dbg
>  recommend would have been dropped before the release.)

Note that you're making work for the installation team here. 

First, it's hard to tell which recommends are planned to be removed
later, and this makes it hard to tell when there are few enough spurious
recommends that d-i can turn on recommends by default without bloating
the installation.

Secondly, if we decided to ignore the gnome-dbg recommends since it will
be removed, and we turned on recommends, we would be in a position where
we couldn't properly test desktop installs for lenny stable, since the
desktop installation would be much larger than it's planned to be in
stable. So we'd not be able to test partman-auto recipes and so on to
make sure they provide enough space; we'd not be able to catch whether
tasksel disables the desktop task properly when there's not enough disk
space; the installation manual wouldn't properly document how much space
the desktop task uses; if we included recommends on CDs, we'd not be
able to tell if gnome fit on a CD; and so on.

Pushing all this work back to shortly before the next stable release is
not a good thing.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Oleg Verych]

>>   unset foo
>>   [ -n $foo ] && echo foo is non-empty
>>   [[ -n $foo ]] && echo foo is non-empty
>>
>> As you can see, only the second one works.
[]
> BTW, i've provided patch in the BTS for dash's test built-in to have
> arithmetic checking of an empty argument and zero right. This was nearly
> a month ago, yet nothing happened.

Also, let me share a hint for speed-optimized scripting.

`-n' and `-z' test cases are completely bogus w.r.t. speed and bugs
mentioned. I would suggest to use ${#foo} and compare size
arithmetically. Because if $foo is big, you are passing it to another
program, built-in or not, doesn't matter. And ${#foo} is always
non-empty expansion, thus one may omit quoiting.

That's why i have patches for arithmetics and asked this list about
using long (as it stated in POSIX) for better usage on 64bit platforms.

The dash's upstream is on vocation or something similar, because same
question aren't answered also. I would like to contribute more, but
lack of feedback is a bad thing. I wonder how all that SoC actually
goes in this period :-/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: needs=vc as menu field useful and needed?

[Nico Golde]

Hi,
* Joey Hess <[EMAIL PROTECTED]> [2007-08-02 19:15]:
> Nico Golde wrote:
> > dvisvga:   Tag: interface::svga, role::program, scope::utility, 
> > use::viewing, works-with::text, works-with-format::dvi
> > luxman:Tag: game::arcade, interface::svga, interface::x11, 
> > role::program, use::gameplaying, x11::application
> > lxdoom-svga:   Tag: game::arcade, interface::3d, role::program, 
> > use::gameplaying
> > svncviewer:Tag: interface::svga, network::client, role::program, 
> > use::login, use::viewing
> > thrust:Tag: game::arcade, interface::svga, junior::arcade, 
> > role::program, use::gameplaying
> 
> These at least clearly use svgalib.

True. I didn't check them all in detail, just saw lots of 
them had interface::x11 and I thought all these packages 
can't be really have buggy menu files :)

> > When looking at the tags it doesn't look like the programs can't run in an X
> > terminal. I tried worms from bsdgames, cadubi and pinball (randomly picked) 
> > and they all
> > worked flawless in my aterm.
> 
> I may have had a reason to make worms needs=vc. IIRC it locks up certian
> dumb terminals due to spewing so much data at the terminal. However my
> reasons for doing it has been lost in the mists of 1995 and I reverted
> it.

Hehe

> A lintian test for needs=vc programs that are not linked with svgalib
> or directfb would be nice.

Oh that is a good idea. I will file a wishlist bug.
Kind regards
Nico

-- 
Nico Golde - http://ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.


pgpDRcQoolw9M.pgp
Description: PGP signature

Re: intent to hijack gsasl

[Russ Allbery]

Jorge Salamero Sanz <[EMAIL PROTECTED]> writes:

> the gsasl, libgsasl7 and libgsasl7-dev packages have not seen an upload
> since 2006-03-16 [0].

> there have been, however, several new upstream versions available which
> have been reported in the BTS [1].

> this issue was raised again in -devel more than a month ago, ccing
> maintainer and sponsor [2] neither of both replied. in fact i had
> contacted them before without reply.  i'm really interesed in
> maintaining those packages, which are build-dep for jabberd2, where i'm
> currently working.

> thus, i intent to hijack src:gsasl unless anyone gives me a good reason
> not to do so.

Simon Josefsson helps maintain Debian packges for several of his other
packages (gss, shishi) and may be willing to help.  He's also generally
great about staying in touch with the Debian maintainers of his packages
and might know more about what's going on.  Have you talked to him about
this?  You may want to set up something like what we have with gss and
shishi where the Debian packaging is maintained on Savannah and Simon is a
listed co-maintainer.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: intent to hijack gsasl

[Jorge Salamero Sanz]

On Thursday 02 August 2007 21:06:10 Russ Allbery wrote:
> Simon Josefsson helps maintain Debian packges for several of his other
> packages (gss, shishi) and may be willing to help.  He's also generally
> great about staying in touch with the Debian maintainers of his packages
> and might know more about what's going on.  Have you talked to him about
> this?  You may want to set up something like what we have with gss and
> shishi where the Debian packaging is maintained on Savannah and Simon is a
> listed co-maintainer.

yes, he knows this hijack and he has suggested me to also take care of 
libntlm0, maintained by the same missing person than gsasl.

simon is very helpfull with me, and yes, have him listed as co-maintainer is 
great idea, we'll talk about that.


signature.asc
Description: This is a digitally signed message part.

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Don Armstrong wrote:
> If they don't enable core dumps in the default config, the backtraces
> aren't going to be terribly useful (or may not even exist), right?
> Then the -dbg packages aren't going to help much either.

 Do you suggest that running gdb on a core dumps makes backtraces nicer?
 Currently, most backtraces we get are either generated by running the
 application from gdb and reproducing the bug or running a segv handler
 such as libgnomeui's (which spawns bug-buddy or debreaper IIRC).

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Loïc Minier]

On Thu, Aug 02, 2007, Joey Hess wrote:
> Pushing all this work back to shortly before the next stable release is
> not a good thing.

 That's a good rationale; I had mixed feelings when I saw this change,
 but now I feel it's better to try to have a constant target all over
 the release cycle; this meets my feeling that testing users are an
 important user base which shouldn't suffer from the change either.

 I've downgraded the dependency in SVN even more (to a suggest).

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Don Armstrong]

On Thu, 02 Aug 2007, Loïc Minier wrote:
> On Thu, Aug 02, 2007, Don Armstrong wrote:
> > If they don't enable core dumps in the default config, the backtraces
> > aren't going to be terribly useful (or may not even exist), right?
> > Then the -dbg packages aren't going to help much either.
> 
>  Do you suggest that running gdb on a core dumps makes backtraces
>  nicer?

I don't know actually; I've never used the libgnome SEGV handler.

>  Currently, most backtraces we get are either generated by running
>  the application from gdb and reproducing the bug or running a segv
>  handler such as libgnomeui's (which spawns bug-buddy or debreaper
>  IIRC).

It may be that the right thing to do is:

1) Segv handler saves the coredump if the user says to (or coredumps
   are on)

2) bug-buddy or debreaper (or whatever) 
   a) prompts to install appropriate -dbg packages if they're not
  already available;
   b) backtraces the coredump from the segv handler using gdb (or
  whatever)
   c) appends that to the bug report
   d) possibly stores the coredump somewhere for future
  reference/debugging.

[With the caveat that I am not familiar with the gnome internals;
someone else can probably adapt the above more appropriately.]


Don Armstrong

-- 
"The trouble with you, Ibid" he said, "is that you think you're the
biggest bloody authority on everything"
 -- Terry Pratchet _Pyramids_ p146

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: intent to hijack gsasl

[Simon Josefsson]

Jorge Salamero Sanz <[EMAIL PROTECTED]> writes:

> On Thursday 02 August 2007 21:06:10 Russ Allbery wrote:
>> Simon Josefsson helps maintain Debian packges for several of his other
>> packages (gss, shishi) and may be willing to help.  He's also generally
>> great about staying in touch with the Debian maintainers of his packages
>> and might know more about what's going on.  Have you talked to him about
>> this?  You may want to set up something like what we have with gss and
>> shishi where the Debian packaging is maintained on Savannah and Simon is a
>> listed co-maintainer.
>
> yes, he knows this hijack and he has suggested me to also take care of 
> libntlm0, maintained by the same missing person than gsasl.

FWIW, I also exchanged many e-mails with the earlier gsasl maintainer,
and he was about to add the NTLM stuff, but after that I never heard
anything again (although I don't recall sending any e-mails myself).

> simon is very helpfull with me, and yes, have him listed as co-maintainer is 
> great idea, we'll talk about that.

I don't care strongly here, I'm satisfied just sending bug reports about
things I miss.  Well, as long as there is someone as responsive as you
are in resolving the issues, of course...

Btw, perhaps we could discuss changing the GSS-API implementation that
gsasl use from libkrb53 to libgss0..  alternatively, providing a new
libgsasl-gss package for this purpose (although that would require
building the source twice).  I would find it very useful to be able to
use Shishi/GSS via GSASL.

/Simon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Michael Vogt]

On Wed, Aug 01, 2007 at 07:28:27PM +0200, Marco d'Itri wrote:
> On Aug 01, Michael Vogt <[EMAIL PROTECTED]> wrote:
> 
> > We, the APT Development Team, will change apt to install recommended
> > packages by default on October 1st. This should give enough time to
> Why? What is the point?

The change is meant to make apt follow policy. Policy says:

Recommends
This declares a strong, but not absolute, dependency.
The Recommends field should list packages that would be found
together with this one in all but unusual installations.

apt never really followed that policy. This lead to the current
situation where recommends are used a lot when they are not really
appropriate because only aptitude and dselect enforced them.

If the majority of people feel that the policy is wrong or does not
reflect reality, then we should change policy. But I think the current
wording ("in all but unusual installations") is pretty clear. 

Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Michael Vogt]

On Wed, Aug 01, 2007 at 01:35:56PM -0700, Russ Allbery wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> 
> > This is not a question of removing choice.  This change in apt is the
> > only thing that *gives* you a choice of installing recommends via apt.
> > That the solution for disabling this in your use case is not immediately
> > obvious is not a reason to not adopt a reasonable default in apt.
> 
> I think it's also particularly annoying for our two major recommended
> package installation interfaces, aptitude and apt-get, to do the opposite
> thing by default with this core of a feature.  What a recipe for
> confusion for the average user who doesn't know the history and doesn't
> choose them based on their Recommends-handling behavior!  We shouldn't be
> substituting tool selection for configuration.

Recently apt and aptitude got closer together again and share the
recommends logic and the automatic depenency information now. I'm very
happy about this. Daniel Burrows did a lot of great work in this area
(thanks!). 

This should minimize one source of confusion at least :)

Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Packaging a difficult project

[Brendon Costa]

Hi all,

I was directed here from debian-mentors with my question.


--- Original Post ---

I have a software project that I plan on creating Debian packages for
which is quite different from many other packages in that it also 
installs patched versions of GCC and Doxygen (That must not conflict 
with existing installs of these programs).


http://edoc.sourceforge.net/

--- Project Description ---
EDoc++ is a compile time C++ exception analysis/documentation tool.

EDoc++ is a tool that analyses exception usage in C++ source code to
provide compile time/static analysis checks similar to that found in
other languages such as Java. EDoc++ can also generate detailed
information about exception propagation in various formats. One of which
can be used by doxygen in documenting exception information for API's.
--- End: Project Description ---



This project has a set of patches against GCC 4.0.1 that create a 
"modified GCC" which exports data while compiling C/C++ programs. This 
data is then used for performing source code analysis (In particular 
analysing information relevant to C++ exception propagation).



Much of the project is easy to break into separate packages, I.e.
creating separate packages for the libs, apps and dev environments.
However the patched versions of GCC and Doxygen that are also required
by EDoc++ can't be installed in standard locations as they may conflict
with existing installed GCC and Doxygen.

The idea is that this patched GCC/Doxygen should be installed
"alongside" existing GCC/Doxygen versions and should not interfere with
them. Currently if the EDoc++ project is configured and built as shown
below:

./configure --prefix=/usr &&
make &&
make install

Then the EDoc++ specific apps, libs etc are installed as expected into
/usr/bin, usr/lib ..., however the patched version of GCC and Doxygen 
are installed to: /usr/edoc_patched/bin, /usr/edoc_patched/lib ...


When EDoc++ is configured and built, the patched source for GCC and
Doxygen are currently configured with a prefix like: gcc/configure
--prefix=${prefix}/edoc_patched

I have been thinking of setting the GCC & Doxygen prefix values to one
of: $bindir/edoc_patched, $datadir/edoc_patched or
$libexecdir/edoc_patched instead of $prefix/edoc_patched. I think the
important thing to note here though is that they can't have their prefix
the same as that of the "normal" programs i.e. /usr, otherwise there is
a chance of conflicts between patched and non-patched GCC/Doxygen.

Does anyone have suggestions as to how best I can tackle this problem in
a way that would be considered acceptable for inclusion in debian? The
current method works fine, but does not meet the debian policy requirements.


I plan on creating the following packages:

edoc
edoc-doc
libedoc
libedoc-dev
libedocbfd
libedocbfd-dev

Would people suggest that the patched gcc/doxygen be included as part of
a main: edoc package, or as separate packages called: "edoc-gcc",
"edoc-doxygen"?

Thanks,
Brendon.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Packaging a difficult project

[Steve Langasek]

On Fri, Aug 03, 2007 at 07:46:44AM +1000, Brendon Costa wrote:
> I have a software project that I plan on creating Debian packages for
> which is quite different from many other packages in that it also 
> installs patched versions of GCC and Doxygen (That must not conflict 
> with existing installs of these programs).

> http://edoc.sourceforge.net/

> --- Project Description ---
> EDoc++ is a compile time C++ exception analysis/documentation tool.

> EDoc++ is a tool that analyses exception usage in C++ source code to
> provide compile time/static analysis checks similar to that found in
> other languages such as Java. EDoc++ can also generate detailed
> information about exception propagation in various formats. One of which
> can be used by doxygen in documenting exception information for API's.
> --- End: Project Description ---

> This project has a set of patches against GCC 4.0.1 that create a 
> "modified GCC" which exports data while compiling C/C++ programs. This 
> data is then used for performing source code analysis (In particular 
> analysing information relevant to C++ exception propagation).

Hmm, I would question whether this is something we'd want to include in the
Debian archive as-is; I think we already have way too many gcc packages
being carried around with our releases and that we need to try to make this
number go down, not add more copies of the gcc source code to the archive.

> The idea is that this patched GCC/Doxygen should be installed
> "alongside" existing GCC/Doxygen versions and should not interfere with
> them.

> Does anyone have suggestions as to how best I can tackle this problem in
> a way that would be considered acceptable for inclusion in debian? The
> current method works fine, but does not meet the debian policy requirements.

I would recommend that you look into the Debian diff for the gcc-4.1 source
package, to see how putting the version number into the binary name is
handled ("gcc-4.1", "cpp-4.1", ...).  The same could be done for edoc, which
would be policy-compliant.

Since gcc-4.0 itself is no longer part of Debian (except for libgcc2 on
hppa), you might even use the same naming scheme and have your package
Conflicts/Replaces/Provides gcc-4.0, cpp-4.0, g++-4.0, and anything else
needed.

> I plan on creating the following packages:

> edoc
> edoc-doc
> libedoc
> libedoc-dev
> libedocbfd
> libedocbfd-dev

> Would people suggest that the patched gcc/doxygen be included as part of
> a main: edoc package, or as separate packages called: "edoc-gcc",
> "edoc-doxygen"?

Given the aim of the edoc framework, I don't see any reason you would want
to split those into separate packages.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Michael Vogt]

On Thu, Aug 02, 2007 at 06:35:40PM +0200, Joey Schulze wrote:
> Reinhard Tartler wrote:
> > Joey Schulze <[EMAIL PROTECTED]> writes:
> > 
> > > Shouldn't we then remove recommends entirely and turn them into
> > > regular Depends?
> > 
> > The sometime 'soft dependencies' called feature of Recommends and
> > Suggests is something which makes Debian unique compared to other
> > distributions. It would be sad to loose this.
> 
> Don't we lose it already on October 1st when apt-get installs all
> Recommends per default?  It's ok for high-level tools like aptitude
> and Synaptic to behave that way, but I'm not exactly happy for
> apt-get to go that way.
[..]
 
I understand your concern, but I do not thing it will be like this. I
think it will make debian better by making it more flexible. It could
even lead to a *smaller* debian as some things that are currently
depends could become recommends. 

Take for example "gksu". It a wonderful application and a lot of
packages depend on it. My impression is that a lot of those depends
are because gksu is used in a .desktop file to start the application.
This seems to be the case for e.g. firestarter. Strictly speaking gksu
is not really a depends, the package works perfectly without gksu. So
it should be a recommend and powerusers can remove it (they use the
terminal anyway to start stuff). I'm pretty sure there are more such
examples.

The current recommends situaton is bad, but as I see it we have two 
options:
a) change policy and say recommends should really be suggests
b) fix apt and go through the transition pain

Letting the current situation drag on forever is not really a solution
IMHO. And we have time to fix the reommends chain and to fix the tools
to better distinguish between real depends and recommends (that is not
ideal currently).

It is possible to see what packages got installed because they were
pulled in as recommends of other package. This makes use of the
automatic install information. With the current apt you can run:

# apt-get autoremove -o APT::AutoRemove::RecommendsImportant=false

to get those packages. There is currently no easy way to get this in
synaptic but that should be straightforward to implement. 

In summary I think that depends will not become another form of
depends and people will forget about them. Just the oposite, it will
be a benefit especially for the powerusers. Regular users will just
ignore them.

I understand that a lot of people are  not happy about a change like
this, but I think recommends-cleanup and improving our tools should
really make debian better and there is still time to work on the
remaining issues :) I guess my initial mail should have included much
more details and examples to explain the rational better.

Cheers,
 Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Don Armstrong]

On Fri, 03 Aug 2007, Josselin Mouette wrote:
> Le jeudi 02 août 2007 à 13:29 -0700, Don Armstrong a écrit :
> > d) possibly stores the coredump somewhere for future
> >reference/debugging.
> 
> Not without prompting. For reference, an epiphany coredump is between
> 200 and 300 MB.

I'd envisioned some sort of prompt or preference; sounds good! [$DEITY
forbid firefox cores...]



Don Armstrong

-- 
Clothes make the man. Naked people have little or no influence on
society.
 -- Mark Twain 

http://www.donarmstrong.com  http://rzlab.ucr.edu

Re: Installation of Recommends by default on October 1st

[Josselin Mouette]

Le jeudi 02 août 2007 à 13:29 -0700, Don Armstrong a écrit :
> 1) Segv handler saves the coredump if the user says to (or coredumps
>are on)
> 
> 2) bug-buddy or debreaper (or whatever) 
>a) prompts to install appropriate -dbg packages if they're not
>   already available;
>b) backtraces the coredump from the segv handler using gdb (or
>   whatever)
>c) appends that to the bug report

This is exactly what I've been planning to add to debreaper, but I still
haven't found the time.

>d) possibly stores the coredump somewhere for future
>   reference/debugging.

Not without prompting. For reference, an epiphany coredump is between
200 and 300 MB.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Installation of Recommends by default on October 1st

[Manoj Srivastava]

On Thu, 2 Aug 2007 15:51:50 +0200, Magnus Holmgren <[EMAIL PROTECTED]> said: 

> On Thursday 02 August 2007 12:01, Julien BLACHE wrote:
>> I'd use aptitude if I wanted Recommends installed by default. I'm
>> using apt-get precisely because it's not doing this kind of stupid
>> things.

> I use aptitude and I don't want Recommends to be installed by
> default. This is not Windows. Here you can configure your software the
> way you want it.

,[  Manual page aptitude(8) ]
|-R, --without-recommends
|Do not treat recommendations as dependencies when installing new
|packages (this overrides settings in /etc/apt/apt.conf and
|~/.aptitude/config). Packages previously installed due to
|recommendations will not be removed.
| 
|This corresponds to the pair of configuration options
|Aptitude::Recommends-Important and Aptitude::Keep-Recommends.
`

So, there you go. I set Aptitude::Recommends-Important to false,
 but retain Aptitude::Keep-Recommends  as true. (UI do draw the line at
 making Aptitude::Keep-Suggests true.

manoj


-- 
Old age is always fifteen years old than I am. Baruch
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[David Nusinow]

On Thu, Aug 02, 2007 at 10:20:42AM +0200, Loïc Minier wrote:
>  The only alternative I can think of is to propose the installation of
>  the video driver when the hardware is detected; that's way harder to
>  implement though.

Working on it...

 - David Nusinow


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: /bin/sh diversions

[Peter Samuelson]

[Oleg Verych]
> Not quoting possible empty argument is a script writing bug.

Not when you use [[.  This is exactly how [[ is supposed to work; it is
explicitly defined to be shell syntax, as opposed to a builtin command,
so it is allowed to "cheat" with argument quoting.  If you don't like
that, don't use [[ ... but if you're going to implement it, implement
it correctly.  A simple alias to [ is not correct.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: /bin/sh diversions

[Thorsten Glaser]

Thanks for keeping me in the Cc ☺ (but I guess I earned that from a PR)

Marco d'Itri dixit:

>Bad idea

Give the user the tools to shoot himself into the foot. Besides, dash
is already using the debconf dance, so why discriminate other shells
that are fine to do it according to policy?

>bash (the standard

Which standard? It's not even POSIX conformant because of its extensions.
Most operating systems don't come with GNU bash either.

>which works with everything

set -A foo
find . -name \*mp3 |&
while read name; do foo[${#foo[*]}]=$name; done
mpg123 -z "[EMAIL PROTECTED]"

I see two things in this (here splitted) one-liner I use often that don't
work with bash, which is expected, as they are features of the Korn shell.

Please don't just say GNU/Linux/ELF/ILP32/i386 is everything; open minds.

//mirabile
-- 
I believe no one can invent an algorithm. One just happens to hit upon it
when God enlightens him. Or only God invents algorithms, we merely copy them.
If you don't believe in God, just consider God as Nature if you won't deny
existence.  -- Coywolf Qi Hunt

Re: /bin/sh diversions

[Thorsten Glaser]

Oleg Verych dixit:

>02-08-2007, Peter Samuelson:

>>   unset foo
>>   [ -n $foo ] && echo foo is non-empty
>>   [[ -n $foo ]] && echo foo is non-empty
>>
>> As you can see, only the second one works.

True, that's why the Korn shell invented [[.

>Not quoting possible empty argument is a script writing bug.

This is actually wrong; in some cases, additional quoting is
a bug (think of “backticks”, which you shouldn't use anyway,
but I don't have a better example right now, except for the
operators to [[ which must be unquoted) or at least undesi-
rable (the argument to “case”, for example), and [[ was spe-
cifically designed to NOT expand its arguments as if they
were arguments to an external programme.

 [[ expression ]]
 Similar to the test and [ ... ] commands (described later), with
 the following exceptions:

 + o Field splitting and file name generation are not per-
   formed on arguments.

 + o The -a (AND) and -o (OR) operators are replaced with
   '&&' and '||', respectively.

 + o Operators (e.g. '-f', '=', '!') must be unquoted.

 + o The second operand of the '!=' and '=' expressions are
   patterns (e.g. the comparison [[ foobar = f*r ]]
   succeeds).

 + o The single argument form of test, which tests if the
   argument has a non-zero length, is not valid; explicit
   operators must always be used e.g. instead of [ str ]
   use [[ -n str ]].

 + o Parameter, command, and arithmetic substitutions are
   performed as expressions are evaluated and lazy expres-
   sion evaluation is used for the '&&' and '||' opera-
   tors. This means that in the following statement,
   $(

Re: /bin/sh diversions

[David Lopez Zajara (Er_Maqui)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Pierre Habouzit wrote:
> On Wed, Aug 01, 2007 at 12:53:03PM -0300, Henrique de Moraes Holschuh wrote:
>> On Wed, 01 Aug 2007, Thorsten Glaser wrote:
>>> Henrique de Moraes Holschuh dixit:
 There is just too much crap out there that thinks /bin/sh is bash.
>>> Not in Debian ??? /bin/sh scripts must be POSIX compliant and not use
>> No, not in Debian.
>>
>> But in practice, if many people can't change that away from bash because all
>> sort of *broken* local scripts, and 3rd-party scripts croak, you gain
>> little.
>>
>> OTOH, specifically using something else than /bin/sh for a fast
>> POSIX-with-the-extensions-Debian-mandates shell (i.e. forget posh, but dash
>> is good) does NOT need /bin/sh to point to it, so it can't trip on such
>> issues caused by external factors outside of Debian's control.
> 
>   Afaict ubuntu did the change, and the sky didn't fell apart.
> 
>   And wrt scripts out there, there is 2 kinds of scripts:
>   * the old one that are written by people on obsolete platforms where
> the de facto standard was a local ksh shell, and we can expect those
> to work properly on dash.
>   * the one unclever users have written with /bin/sh pointing to
> /bin/bash. For them, it's easy, just don't change /bin/sh on dash on
> upgrades. Do that only for new installations. And for them, the fix
> is quite easy, they still can use #!/bin/bash.

It's more simple if our scripts or our packages point to #!/bin/dash if
you are looking for a way for moderate resources use.

Can be a error if are scripts who uses #!/bin/sh as bash, but, these
error exists. Are on the packages, and on the client-side. Too, the
users are using bash since long time ago. Now, we can make a change,
but, this can be confuse to the users. You can use literaly dash, or can
make a newer symlink to "smaller sh interpreter" and make them standard
to all developers use this if are looking for a sh interpreter who its
the smallest on the system. But, changing sh target for all users,
without really necesity, can be a chaos.


The changes can be commented, but, are sensitival changes. Its the same
as the "debian menu" discursion on this list. Now, i'm out-to-date on
these chat, but, i can see on my distro who the menu are hidden. My
debian installation its older, and i use this menu, and now, because a
discursion of this theme, i have disappeared the menu from my list. I
can make them to show newly, but, these changes, without any warning to
the users confused them.


- --
[EMAIL PROTECTED]  ||  http://maqui.darkbolt.net
Linux registered user number: #363219
PGP key avaliable at KeyServ. KeyID: 0x4233E9F2
- --
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGspRifFjA4EIz6fIRAg1tAJ9154znzwArWHeaoc7BaQS4KmK3MACgkGLC
cjFRCBRHpsdEY9iT22PeoyQ=
=wYwO
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Installation of Recommends by default on October 1st

[Mike Hommey]

On Thu, Aug 02, 2007 at 06:19:37PM +, Oleg Verych <[EMAIL PROTECTED]> wrote:
> 02-08-2007, Mike Hommey:
> > On Thu, Aug 02, 2007 at 10:01:22AM +0200, Pierre Habouzit <[EMAIL 
> > PROTECTED]> wrote:
> >>   PS: I'm very fond of the apache (to be removed) Recommends. really.
> >>   especially on a notebook, it helps understanding how broken the
> >>   recommends chain is right now.
> >
> > I don't know for your case, but there are packages in debian that can use
> > apache as a file sharing backend. And it's particularly useful on laptops.
> 
> _file_ sharing; another web-like crap?
> 
> The FTP, despite of not being able to follow symlinks, what is the
> problem? That is easily solved by making /home/ftp a symlink to your
> big-file storage.
> 
> I use pure-ftp for sharing. mc, any-web-browser or lftp are OK as
> clients.

Look at gnome-user-share. It uses webdav access and enables the user to
share any directory from nautilus. It is actually convenient for novice
users.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Work-needing packages report for Aug 3, 2007

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 385 (new: 3)
Total number of packages offered up for adoption: 79 (new: 1)
Total number of packages requested help for: 38 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   vpim (#435371), orphaned 2 days ago
 Description: vCard and iCalendar library for Ruby
 Installations reported by Popcon: 28

   wget-el (#435372), orphaned 2 days ago
 Description: an interface for wget on Emacsen
 Installations reported by Popcon: 106

   x2x (#435702), orphaned today
 Description: Link two X displays together, simulating a multiheaded
   display
 Installations reported by Popcon: 410

382 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   pkspxy (#435116), offered 4 days ago
 Description: PGP Public Key Server Proxy Daemon
 Installations reported by Popcon: 16

78 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 770 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot aboot-cross dfsbuild ltsp-client-core
 Installations reported by Popcon: 101

   apt-build (#365427), requested 460 days ago
 Description: Need new developer(s)
 Installations reported by Popcon: 805

   apt-cacher (#403584), requested 227 days ago
 Description: caching proxy system for Debian package and source
   files
 Installations reported by Popcon: 359

   apt-show-versions (#382026), requested 359 days ago
 Description: lists available package versions with distribution
 Installations reported by Popcon: 2778

   athcool (#278442), requested 1010 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 279

   cvs (#354176), requested 525 days ago
 Description: Concurrent Versions System
 Reverse Depends: bonsai crossvc cvs-autoreleasedeb cvs-buildpackage
   cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta (17
   more omitted)
 Installations reported by Popcon: 18664

   dpkg (#282283), requested 985 days ago
 Description: dselect: a user tool to manage Debian packages
 Reverse Depends: alien alsa-source apt-build apt-cross apt-src
   backuppc build-essential bzr-builddeb clamsmtp crosshurd (87 more
   omitted)
 Installations reported by Popcon: 56696

   dsniff (#430162), requested 41 days ago
 Description: Various tools to sniff network traffic for cleartext
   insecurities
 Installations reported by Popcon: 939

   elvis (#432298), requested 24 days ago
 Description: powerful clone of the vi/ex text editor (with X11
   support)
 Reverse Depends: elvis elvis-console elvis-tools
 Installations reported by Popcon: 250

   gentoo (#422498), requested 88 days ago
 Description: a fully GUI-configurable, two-pane X file manager
 Installations reported by Popcon: 263

   grub (#248397), requested 1179 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: dfsbuild replicator
 Installations reported by Popcon: 51629

   ispell-et (#391105), requested 302 days ago
 Description: Estonian dictionary for Aspell/Ispell/MySpell
 Installations reported by Popcon: 32

   kradio (#429873), requested 43 days ago
 Description: Comfortable Radio Application for KDE
 Installations reported by Popcon: 244

   lighttpd (#401575), requested 241 days ago
 Description: A fast webserver with minimal memory footprint
 Reverse Depends: lighttpd-mod-cml lighttpd-mod-magnet
   lighttpd-mod-mysql-vhost lighttpd-mod-trigger-b4-dl
   lighttpd-mod-webdav
 Installations reported by Popcon: 755

   loop-aes-utils (#385614), requested 336 days ago
 Description: Tools for mounting and manipulating filesystems
 Reverse Depends: loop-aes-modules-2.6.21-2-486
   loop-aes-modules-2.6.21-2-4kc-malta loop-aes-modules-2.6.21-2-686
   loop-aes-modules-2.6.21-2-686-bigmem
   loop-aes-modules-2.6.21-2-alpha-generic
   loop-aes-modules-2.6.21-2-alpha-legacy
   loop-aes-modules-2.6.21-2-alpha-smp loop-aes-modules-2.6.21-2-amd64
   loop-aes-modules-2.6.21-2-footbridge
   loop-aes-modules-2.6.21-2-iop32x (32 more omitted)
 Installations reported by Popcon: 672

   mc (#380999), r

adduser/deluser on postinst

[Vincent Bernat]

Hi !

I need some  advice on bug #435671.  I agree with  the bug reporter that
the user  handling part of  xrdp should be  rewritten. I have  looked at
what is done  in other packages and  in most of them gentent  is used to
check the  user existence but  there is no  check that this is  really a
system user  (so the user can  be unrelated to the  package). Because of
this,  some  package (ntp)  just  skip the  test  and  use adduser  with
--quiet.

On  deletion, some package  do not  use --system  option of  deluser, so
delete a legit  non-system user without warning. On  my system, there is
gdm, openntpd, openssh and vde2.

In summary, I  think a package should just  use adduser --quiet --system
in postinst and  deluser --quiet --system on purge  without checking for
existence. It would be convenient for adduser --quiet --system to return
an error if the user exists  but is not a system user (actually, without
--quiet, it says the user exists and is a user system, I will report the
bug).

What do you think ?
-- 
BOFH excuse #45:
virus attack, luser responsible


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]