Re: Possible mass bug filing: non-doc packages recommending doc packages

[Y Giridhar Appaji Nag]

On 09/05/07 17:55 +0530, Y Giridhar Appaji Nag said ...
> I filed a lintian wishlist bug (#527363) requesting a I/W tag when non
> documentation packages recommend documentation packages.
> 
> With Install-Recommends being the default, many packages pull in a lot of
> associated documentation.  These documentation packages are sometimes large
> and could be suggested rather than recommended.  I noticed different opinions
> about such bugs on the BTS (See #504042 that went on to be fixed and #526153
> that was not).  I understand that upstream would sometimes like documentation
> to be installed alongside the binaries, but popcon numbers of -doc packages
> are quite lower the numbers corresponding to the packages that recommend them.
> 
> Would there be any objections to filing minor/wishlist bugs against these
> packages?  I am including a tentative dd-list corresponding to the packages
> [1] that I found after manually removing some packages [2].  I will modify it
> based on suggestions.

Based on the responses, I will not file bugs on all these packages and also
see if my request for lintian check makes more sense if it is refined.

Thank you all for the comments.

Giridhar

-- 
Y Giridhar Appaji Nag | http://people.debian.org/~appaji/


signature.asc
Description: Digital signature

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

Raphael Hertzog  writes:
> On Mon, 11 May 2009, Russ Allbery wrote:

>> I still think Build-Options-Supported is fundamentally the wrong way
>> to implement that.  You have to modify every package to add it
>> anyway, in which case you can just as easily support it in the
>> package's debian/rules the way that we already support various other
>> DEB_BUILD_OPTIONS settings.

> Except that with the centralized approach we can have an opt-out
> policy after some time (ie use hardening options by default except for
> packages that have set no-hardening).

That seems orthogonal.  Either way, you have to get most package
maintainers to modify their packages and test to be sure that you can
change the default build flags.  Either way, the results of that change
will produce artifacts that you can look for to see how many packages
are currently building with the new flags.  Either way, there is a way
for maintainers to opt out of default flags.

I understand conceptually how Build-Options-Supported could be useful,
but I've yet to see a specific application for it that doesn't seem like
it would be better done some other way.  For example, saying that you
support parallel builds there seems inferior to just enabling parallel
builds if the DEB_BUILD_OPTIONS flag is set and you support it.  Opting
in to specific features similarly makes more sense as DEB_BUILD_OPTIONS
to me.  Opting out of default flags can be done with make's filter
support.  build-arch/build-indep should just be *done* rather than
asking packages to say whether they support it, IMO.

> My interest in centralizing those is simplifying any transition in
> default flags that Debian would want to do. User customization is nice
> but it's not what motivates me to push this forward.

Sure, that's the point of the whole discussion: how best to do that
across the archive and whether we should break debian/rules build in
order to do so.  I think there's general agreement on the goal.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

On Mon, 11 May 2009, Manoj Srivastava wrote:
> > If you refer to the fact, that dpkg-buildpackage cleans and rebuilds
> > everything and that it can take a lot of time, then please stop using
> > arguments that do not hold at all. you can call arbitrary debian/rules
> > targets with dpkg-buildpackage (without calling the clean rule
> > before-hand) and I pointed that to you multiple times already.
> > It's in dpkg 1.15.x (in experimental right now, in sid this week) and
> > it's the --target option.
> 
> Nice rant about a facility that is not yet in proper
>  distribution (ustable, testing, or stable).

You have however "-nc" since a long time and if you have proper Make
dependencies it should be pretty quick by not redoing unnecessary work.

Furthermore, we're designing stuff for the future so you have no reason
to dismiss that fact even if it's not yet in sid.

> So, until a date in the future at this point, using
>  dpkg-buildpackageis a resource hog, and no, you have not told me
>  multiple times.

Right I have not repeated it multiple times in the discussion because
I try to avoid that but it was in the initial wiki page that started this
discussion: http://wiki.debian.org/Teams/Dpkg/DebianRules

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Raphael Hertzog]

On Mon, 11 May 2009, Russ Allbery wrote:
> Raphael Hertzog  writes:
> 
> > BTW, just to make things clear. It's likely that those Makefile
> > snippet (if we decide to go that way) become quite more elaborated as
> > we try integrating support for things like hardening-wrapper (see
> > #489771).  Expect stuff like "if debian/control has
> > Build-Options-Supported:  hardening" then use that set of flags,
> > otherwise that one.
> 
> I still think Build-Options-Supported is fundamentally the wrong way to
> implement that.  You have to modify every package to add it anyway, in
> which case you can just as easily support it in the package's
> debian/rules the way that we already support various other
> DEB_BUILD_OPTIONS settings.

Except that with the centralized approach we can have an opt-out policy
after some time (ie use hardening options by default except for packages
that have set no-hardening).

My interest in centralizing those is simplifying any transition in
default flags that Debian would want to do. User customization is nice
but it's not what motivates me to push this forward.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[David Nusinow]

Y Giridhar Appaji Nag wrote:
> Hi debian-devel,
> 
> From policy 7.2 Binary Dependencies - Depends, Recommends, Suggests, Enhances,
> Pre-Depends
> 
> 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.
> 
> Suggests
> 
> This is used to declare that one package may be more useful with one or
> more others. Using this field tells the packaging system and the user that
> the listed packages are related to this one and can perhaps enhance its
> usefulness, but that installing this one without them is perfectly
> reasonable.
> 
> I filed a lintian wishlist bug (#527363) requesting a I/W tag when non
> documentation packages recommend documentation packages.
> 
> With Install-Recommends being the default, many packages pull in a lot of
> associated documentation.  These documentation packages are sometimes large
> and could be suggested rather than recommended.  I noticed different opinions
> about such bugs on the BTS (See #504042 that went on to be fixed and #526153
> that was not).  I understand that upstream would sometimes like documentation
> to be installed alongside the binaries, but popcon numbers of -doc packages
> are quite lower the numbers corresponding to the packages that recommend them.
> 
> Would there be any objections to filing minor/wishlist bugs against these
> packages?  I am including a tentative dd-list corresponding to the packages
> [1] that I found after manually removing some packages [2].  I will modify it
> based on suggestions.
> 
> [1] grep-dctrl --pattern="-doc" --field=Recommends --and --not \
> --pattern="-dev" --field=Package --show-field=Package
> [2] Mostly haskell, tcl/tk, texlive and gtk/gnome documentation packages a few
> others like emacs-goodies-el, twisted-doc etc.
> 



> I wonder if I should remove the following packages from the list.
> Debian X Strike Force 
>xorg

I've now begun taking care of this. xorg currently recommends xorg-docs,
which contains several manpages that we consider standard for any X
installation. Unfortunately, it also contains several other docs that
aren't as necessary. What I've just done is uploaded a new version of
xorg-docs to unstable that splits off a new xorg-docs-core package that
contains these manpages. The xorg package in our git repository now
depends on this -core package, and moves xorg-docs to suggests where
it's more appropriate.

Once we upload a new version of xorg, it'll still appear on your scan,
but at that point we'll be considering it a false positive. Thanks for
bringing this to my attention.

 - David Nusinow


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

Roger Leigh  writes:

> On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote:
>> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>> > A read-only / should work out of the box just like a read-only /usr. I
>> > haven't installed a fresh one in a long while though so if you know of
>> > problems speak up so bugs can be filed and packages can be fixed.
>> 
>> Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
>> frankly, I do not have the time to muck with that right now.
>
> #494001 is the main blocker.  It's just waiting for the patch to be
> applied AFAICT.

Ok, that one doesn't work out of the box but is easily rectified by
the admin. But it has been known a long time and is finaly fixable.

Should have said unknown bugs. :)

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Using uscan with VCS hosting sites

[Gunnar Wolf]

Ben Finney dijo [Wed, May 06, 2009 at 04:31:02PM +1000]:
> [no answers for this yet on ‘debian-mentors’, so trying here]
> 
> Howdy all,
> 
> I have an upstream for a package who has started using a VCS hosting
> site for publishing the code. It's possible they will continue to make
> tarball releases, but in case they don't at some point in the future,
> I'd like to use this as an opportunity to learn the capabilities of
> ‘uscan’.
> 
> The package in question is ‘python-coverage’, and already has a
> ‘debian/watch’ file:
> 
> =
> […]
> # Current version from Ned Batchelder's site
> http://nedbatchelder.com/code/modules/coverage.html \
> code/modules/coverage-(.*).tar.gz
> =
> 
> The author is now publishing their source code for this package at
> http://bitbucket.org/ned/coveragepy/>, a project hosting site using
> Mercurial for VCS. That service makes available URLs for tags in VCS
> repositories, but the tags are not in the URLs themselves, only in the
> text of the ‘A’ elements:
> (...)

Your situation seems similar to what I faced with github - I set up a
redirector at http://githubredir.debian.net/ - This takes a Git tree
as exported by Github and gives the links for each of the tags. 

Now, there are some caveats - Mainly, the orig.tar.gz files are not
_always_ identical, I guess due to timestamping differences. But it
works for me. And source code is available from the page.

Greetings,

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Mike Hommey]

On Mon, May 11, 2009 at 04:38:59PM +0100, Roger Leigh  
wrote:
> There's a patch for /etc/mtab elimination; it's totally unneeded nowadays.

More than unneeded, it is absolutely irrelevant when using mount namespaces.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#528273: ITP: twittare -- A Twitter client for Linux written in Qt

[Dominik George]

Package: wnpp
Severity: wishlist
Owner: Dominik George 

* Package name: twittare
  Version : 0.7.42
  Upstream Author : TabaréCaorsi 
* URL : http://www.twittare.com/
* License : GPL-3+
  Programming Lang: C++
  Description : A Twitter client for Linux written in Qt

Twittare is a twitter client for Linux written in Qt with notification support.
It contains support for receiving status updates from friends, sending new
stausses as well as replying and retwitting.

The user is notified through a balloon tip when a new tweet is received so
there is instant knowledge of status changes.
  

-- System Information:
Debian Release: 5.0.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Jakub Wilk]

* Simon Josefsson , 2009-05-11, 15:06:

What about msmtp?  http://msmtp.sourceforge.net/

AFAIK msmtp does not support local mail delivery.


I suspect that is part of the design goal of msmtp.  Local mail delivery
can be handled by other tools, can't it?  Generally, it seems like a
good idea to separate these two separate tasks into different tools.
Well, if anybody knows how to couple msmtp with an MDA, I'd be glad to 
see a solution.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[Announce] Intel and Nokia announce open source telephony project (oFono)

[Aki Niemi]

Intel and Nokia are pleased to jointly announce the oFono project
(http://ofono.org), an open source project for developing an open source
telephony solution.

oFono.org is a place to bring developers together around designing an
infrastructure for building mobile telephony (GSM/UMTS) applications.
oFono.org is licensed under GPLv2, and it includes a high-level D-Bus
API for use by telephony applications of any license.  oFono.org also
includes a low-level plug-in API for integrating with Open Source as
well as third party telephony stacks, cellular modems and storage
back-ends.  The plug-in API functionality is modeled on public
standards, in particular 3GPP TS 27.007 "AT command set for User
Equipment (UE)."

Source code is available on http://ofono.org/downloads and a high-level
architecture diagram is available on http://ofono.org/documentation.  To
join the mailing list, go to http://lists.ofono.org/listinfo/ofono.

Nokia and Intel will jointly maintain the oFono project.  We'd like to
invite all developers to join the oFono.org effort and community.

Marcel Holtmann , Intel Open Source Technology
Center
Aki Niemi , Nokia Devices R&D, Maemo Software


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#528247: ITP: python-django-djapian -- Full-text search for Django

[Mikhail Lukyanchenko]

Package: wnpp
Severity: wishlist
Owner: Mikhail Lukyanchenko 


* Package name: python-django-djapian
  Version : 2.2.1
* URL : http://code.google.com/p/djapian/
* License : BSD
  Programming Lang: Python
  Description : Search API for Django with Xapian



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Gabor Gombas]

On Mon, May 11, 2009 at 03:43:41PM +0200, Giacomo A. Catenazzi wrote:

> You are a very special case: a developer since very long time, with a
> enormous knowledge of debian policy (and dpkg internal).
> But I really think that most people outside DD use dpkg-buildpackage
> because it is the easier way (without need to remember a lot of
> details).  I think also that most of DDs use dpkg-buildpackage.

My experiences are quite the contrary: people who are not deeply
involved with Debian tend to run debian/rules directly, and the only
Debian-specific command they know is "dpkg -i --force-depends"...

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:
> Manoj Srivastava wrote:

>> The only builds Debian supports are not just the buildd ones. As
>>  members of the free software community, we should also cater to end
>>  users building, tweaking, and rebuilding our software.

> You are a very special case: a developer since very long time, with a
> enormous knowledge of debian policy (and dpkg internal).  But I really
> think that most people outside DD use dpkg-buildpackage because it is
> the easier way (without need to remember a lot of details).  I think
> also that most of DDs use dpkg-buildpackage.

The number of people using different methods is fairly irrelevant to
Manoj's point.  The question is more fundamental: are packages built by
a makefile that we call debian/rules, or are they built by the program
dpkg-buildpackage using debian/rules as a configuration file for that
program?

If they're built by the program, then anyone who wants to properly build
the software, even if they don't want to go all the way to the package,
will need to use the program, since people will write debian/rules such
that it assumes the program is in use.  They'll assume default CFLAGS
are set and so forth.

I don't think this is the right direction to go, but I'm not going to
stomp off in a huff if we go that direction or anything.  :)  But I do
want to be sure that we're all clear on what we're saying if we do take
that approach and make dpkg-buildpackage the only supported way to build
packages.  I think it's likely that if we go that route, with it
providing the defaults, we'll find over time that some packages will
either not build or will mis-build with debian/rules build and no one
will notice or be particularly interested in fixing it.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Russ Allbery]

Raphael Hertzog  writes:

> BTW, just to make things clear. It's likely that those Makefile
> snippet (if we decide to go that way) become quite more elaborated as
> we try integrating support for things like hardening-wrapper (see
> #489771).  Expect stuff like "if debian/control has
> Build-Options-Supported:  hardening" then use that set of flags,
> otherwise that one.

I still think Build-Options-Supported is fundamentally the wrong way to
implement that.  You have to modify every package to add it anyway, in
which case you can just as easily support it in the package's
debian/rules the way that we already support various other
DEB_BUILD_OPTIONS settings.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Roger Leigh]

On Mon, May 11, 2009 at 09:20:44AM -0500, Manoj Srivastava wrote:
> On Mon, May 11 2009, Goswin von Brederlow wrote:
> 
> > Henrique de Moraes Holschuh  writes:
> >
> >> On Mon, 11 May 2009, Goswin von Brederlow wrote:
> >>> > A separate /usr *is* the way to go if you don't want any writes in
> >>> > that filesystem 99.9% of the time (i.e. when you're not doing an
> >>> > upgrade).
> >>> 
> >>> A read-only / does the trick just as well. And if you don't want
> >>> writes to /usr you probably don't want writes to /bin or /sbin
> >>> either. So read-only / is really the way to go. Not a strong argument
> >>> for a seperate /usr.
> >>
> >> No, RO / is a lot more difficult to pull off (remember: some of us don't
> >> want initrds), while RO /usr is really just a three-char change on fstab
> >> (and if you want apt to remount things automatically, two lines in a config
> >> file).
> >
> > Why would you need an initrd for a read-only /?
> >
> > A read-only / should work out of the box just like a read-only /usr. I
> 
> Except it does not.
> 
> > haven't installed a fresh one in a long while though so if you know of
> > problems speak up so bugs can be filed and packages can be fixed.
> 
> There is the /etc/mtab issue, and then there are things like
>  resolvconf that try to scribble in /etc.  I have not tried recently, so
>  I don't know if there are more blocker.

resolvconf uses /lib/init/rw nowadays, so no /etc writing is needed.

There's a patch for /etc/mtab elimination; it's totally unneeded nowadays.

There may be a few other minor issues, but a read-only root is well in
reach for Squeeze if people try it out and report any remaining cases.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Manoj Srivastava]

On Mon, May 11 2009, Raphael Hertzog wrote:

> On Sun, 10 May 2009, Manoj Srivastava wrote:
>> I would prefer Debian to remain a full fledged member of the free
>>  software community, and continue to not let build behaviour diverge
>>  whether or not dpkg-buildpackage was used -- which can be a substancial
>>  resource hog for multiple binary source packages.
>
> resource hog?? 

That is indeed what I said.

> If you refer to the fact, that dpkg-buildpackage cleans and rebuilds
> everything and that it can take a lot of time, then please stop using
> arguments that do not hold at all. you can call arbitrary debian/rules
> targets with dpkg-buildpackage (without calling the clean rule
> before-hand) and I pointed that to you multiple times already.
> It's in dpkg 1.15.x (in experimental right now, in sid this week) and
> it's the --target option.

Nice rant about a facility that is not yet in proper
 distribution (ustable, testing, or stable).

So, until a date in the future at this point, using
 dpkg-buildpackageis a resource hog, and no, you have not told me
 multiple times.

manoj
-- 
"And remember: Evil will always prevail, because Good is dumb."
Spaceballs
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Manoj Srivastava]

On Mon, May 11 2009, Goswin von Brederlow wrote:

> Henrique de Moraes Holschuh  writes:
>
>> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>>> > A separate /usr *is* the way to go if you don't want any writes in
>>> > that filesystem 99.9% of the time (i.e. when you're not doing an
>>> > upgrade).
>>> 
>>> A read-only / does the trick just as well. And if you don't want
>>> writes to /usr you probably don't want writes to /bin or /sbin
>>> either. So read-only / is really the way to go. Not a strong argument
>>> for a seperate /usr.
>>
>> No, RO / is a lot more difficult to pull off (remember: some of us don't
>> want initrds), while RO /usr is really just a three-char change on fstab
>> (and if you want apt to remount things automatically, two lines in a config
>> file).
>
> Why would you need an initrd for a read-only /?
>
> A read-only / should work out of the box just like a read-only /usr. I

Except it does not.

> haven't installed a fresh one in a long while though so if you know of
> problems speak up so bugs can be filed and packages can be fixed.

There is the /etc/mtab issue, and then there are things like
 resolvconf that try to scribble in /etc.  I have not tried recently, so
 I don't know if there are more blocker. Oh, and /root is a home
 directory; unless we move that,  a read only / would affect root
 negatively.

A read-only / would be nice, but unless you try it on a real
 box, I don't think you assert it should be working out of the box.

manoj

-- 
"Vendi, vidi, parenthesi" -- I came, I saw, I programmed in Lisp!" Dave
W. Kimball
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Tasks field in packages file

[Andreas Tille]

On Fri, 8 May 2009, Lucas Nussbaum wrote in [1]:


Those tasks are read from the Packages files (the Task: field that some
entries have). I'm not sure how this field is managed.


When trying to track down the origin of the task column in UDD[1] I learned
that it is just copied from the task field in the packages file which is
maintained via tasksel.  Please excuse my ignorance but I was simply not
aware that we have such a lot (>300) tasks defined in tasksel - I stupidly
assumed we would have these two hand full which are displayed in the end
of Debian installer.

When reading tasksel-2.78/tasks/README I stumbled upon:

   Care should be taken when adding new tasks to ensure that the new task is
   suitably generic -- it should be something of value to a large number (at
   least 25%) of our users;

and than looking at the tasks which are supporting more than 10 different
languages I can plainly assume that the criterion "at least 25% of our users")
does definitely not fit - without discriminating any specific language it
is not realistic to assume that amharic, arabic, basque, belarusian, bengali,
bosnian, brazilian-portuguese, gujurati, hebrew, hindi, ...) is useful
for 25% of our users each.  Because I think it is important to support
all these languages we should at least fix the readme accordingly.

Mentioning this I wonder what might be a reasonable criterion (and I
wonder whether this list is apropriate because debian-boot is mentioned
as maintainer for tasksel - but I do not see this issue as an
installer specific topic and thus I'd like to keep the discussion here
on this list).

When wearing my Debian Pure Blends hat the term task has some slightly
differnet meaning because each Blend also defines a certain set of tasks.
The same term is used intentionally and historically because the Debian
Edu Blend used to create tasksel input file from a set of tasks files
and thus the source packages of a Blend package like debian-edu, debian-med
etc just contain a tasks directory containing valid tasks files - even if
some more fields were added and interpreted by the Blends tools.  One
part of the output of blends-dev is a *.desc file which is installed to
/usr/share/tasksel/ - so in Debian Pure Blends we using the same technique
but have a different way to propagate the data (inside a $BLEND-tasks
binary package).

My question is now how we might possibly move the information of Blends
tasks into the Packages files.  Well I learned that people here are
concerned about even more information in packages files and I just
assume for a moment this is a wanted behaviour, but for sure this is
a question which should be discussed as well.  My main interest is to
get the information about tasks in to the packages table of UDD.  I
just would not be happy to have different methods to feed this information
into UDD - thus I would prefer the established method via simply parsing
the Packages file.

I see two options to move Blends information to the packageas file:

  1. via tasksel
 The blends-dev could be used to create a patch against
 tasksel and ask tasksel maintainers to include this into
 the tasksel source.  The $BLEND-tasks package might be droped
 in favour of the information which is provided by
 tasksel (>= version including the patch)

 Pro:
 We could profit from the established way to propagate
 Task information to the Packages file.
 Con:
 We loose some flexibility in Blends.

  2. implement own way to populate info to Packages file
 The blends-dev package could move the needed information
 somehow following the way tasksel is doing.  I have read
 that this is done by editing override files - I have no
 idea whether this is up to date information.

 Pro:
 Each Blend remains flexible and we do not require
 any action from tasksel maintainers after releasing
 every single new Blend release.
 Con:
 We need a new way to push task information to
 Packages files.

I slightly tend to prefer the second option but I'm not educated
enough about possible problems that might occure.

What do you think?  What do you think about the third option to
just update the packages table in UDD from a different source than
the packages files?  In principle we also could add another table
tasks - but I would prefer the same technical implementation for
what is finally technically identical: Just selecting a set of
packages.

Any comments are welcome.

Kind regards

 Andreas.

[1] http://lists.debian.org/debian-qa/2009/05/msg8.html

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Giacomo A. Catenazzi]

Manoj Srivastava wrote:

On Sun, May 10 2009, Steve Langasek wrote:


On Sun, May 10, 2009 at 11:37:46PM +0300, Peter Eisentraut wrote:

On Sunday 10 May 2009 13:56:04 Steve Langasek wrote:

I thought it was generally recognized that it's a Bad Idea to implement
config files using your interpreter's 'include' functionality, but that's
basically what we have here.
Guillem pointed out one problem: Either you do it via a make include (which 
you have issues with), or you stop supporting calling debian/rules directly 
(inconvenient, probably prone to break things)

I don't agree that "dpkg-buildpackage sets additional environment
variables to implement a distro/site policy for builds" implies
"calling debian/rules directly is unsupported".  Or maybe I've
misunderstood, and there are Debian developers who are building
official packages for *upload* by calling debian/rules by hand, and
that's what people are concerned about preserving while still getting
the benefits of these distro build flags?


The only builds Debian supports are not just the buildd ones. As
 members of the free software community, we should also cater to end
 users building, tweaking, and rebuilding our software.


You are a very special case: a developer since very long time, with a
enormous knowledge of debian policy (and dpkg internal).
But I really think that most people outside DD use dpkg-buildpackage
because it is the easier way (without need to remember a lot of
details).  I think also that most of DDs use dpkg-buildpackage.

Note: it is also used to do "make clean" before *any* build, because
the non traced dependencies. E.g. on old time, some kernel configurations
needed a "make clean".  I don't think I want to remember when I need
to run "make clean", so any changes on compiler, on configuration or
other heavy changes I run "make clean".  I think for the same reason
people (but people very deep in debian packaging) will use
dpkg-buildpackage: not the optimal way, but it is safer, and with
less "surprises".


A new point, still neglected on this thread:

there are other nasty cases: as we saw in an other thread on debian-policy,
the current locale changes the way wide-characters (and wide strings) are
encoded in binaries (UTF-16 if current charset in current locale could
be encoded in 16-bit; UTF-32 on other cases, and fortunately when no charset
is specified on current locale, thus also on "C" locale).

Wide characters are not common, but they are specified not only in POSIX but
also in standard C (also in C89/C90 version IIRC).
I don't see a good way that:
- developers will do the right things (how many of you doesn know such
  strangeness?)
  [ add a flag to CFLAG in every debian/rules is IMHO not the right thing ]
- it is documented (e.g. on logs), actually we need to parse binaries to
  find what type of encoding did the original uploader (not so complex
  because we have only currently two encoding, but anyway...]
- security team and MNU doesn't break package because of nasty interaction
  because of different locale.

other than using dpkg-buildpackage (and letting dpkg-buildpackage
to set this (and probably other nearly-unknow paramenters)

ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Simon Josefsson]

Jakub Wilk  writes:

> * Simon Josefsson , 2009-05-11, 12:55:
> +1 for ssmtp
 I found ssmtp couldn't cope with mail my various systems were
 generating, something about fixed maximum buffer lengths from memory.
>>>
>>> Please not ssmtp.  If I recall it correctly I found no way to get it
>>> to send mail to a exim-based smarthost via TLS in a sane way.
>>
>>What about msmtp?  http://msmtp.sourceforge.net/
> AFAIK msmtp does not support local mail delivery.

I suspect that is part of the design goal of msmtp.  Local mail delivery
can be handled by other tools, can't it?  Generally, it seems like a
good idea to separate these two separate tasks into different tools.

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Roger Leigh]

On Mon, May 11, 2009 at 09:59:36AM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 11 May 2009, Goswin von Brederlow wrote:
> > A read-only / should work out of the box just like a read-only /usr. I
> > haven't installed a fresh one in a long while though so if you know of
> > problems speak up so bugs can be filed and packages can be fixed.
> 
> Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
> frankly, I do not have the time to muck with that right now.

#494001 is the main blocker.  It's just waiting for the patch to be
applied AFAICT.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Giacomo A. Catenazzi]

Goswin von Brederlow wrote:

Holger Levsen  writes:


Hi,

On Sonntag, 10. Mai 2009, Raphael Hertzog wrote:

With the include approach, we lack this feature and bad/broken local
overrides can't be detected if we only have the build log at hand.
which reminds me that we dont have build logs for probably a lot more than 25% 
(*) of the most used packages in the archive. The ones build manually by the 
developer...


I would really like to see that binaries for all archs are (re-)build on 
builds and that those logs are kept archived and linked from the PTS. (And 
arch all too of course).



regards,
Holger

(*) wild guess, asuming that most packages are upload on amd64/i386/powerpc 
and mostly used on i386.


Debuild already creates a build log. I think it would be nice to
include that file in the changes file and have DAK forward it to
buildd.debian.org for archival. git-buildpackage, svn-buildpackage,
... or even dpkg-buildpackage could do this too.


but I would like to have more :-)
Currently I prefer to build package with --quiet flag, so that I see
easily problems on building package:
I see that a lot of my sponsoree forgot to check *carefully* logs,
to look for deprecated features, or important but non fatal warnings.

So I would like to have a short log (e.g. what I put in stdout/stderr,
with "./configure --quiet"), so that people will have no excuses for
not be carefukll, but also to have access to configure.log (or/and
other build time log), on build failure.

Is it to much to ask?
ciao
cate


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] New hylafax package: getting rid of the twin directories structure

[Giuseppe Sacco]

Il giorno lun, 11/05/2009 alle 15.06 +0200, Marco d'Itri ha scritto:
[...]
> > With 2.6 kernels, we may use the "bind" option in order to mount
> > a /etc/hylafax on /var/spool/hylafax/etc. So, I am finally moving to
> > this new configuration, but I have a few concern that I would like to
> > share, looking for suggestion.
> I am sure that there is a good reason, but what prevents you from making
> the program just use /etc/hylafax? chrooting?

yes, daemons are chrooted in /var/spool/hylafax


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] New hylafax package: getting rid of the twin directories structure

[Marco d'Itri]

On May 11, Giuseppe Sacco  wrote:

> delivering packages that do not work with kernel 2.4. Now I believe that
> 2.4 kernel is no more supported.
This has been true since lenny.

> With 2.6 kernels, we may use the "bind" option in order to mount
> a /etc/hylafax on /var/spool/hylafax/etc. So, I am finally moving to
> this new configuration, but I have a few concern that I would like to
> share, looking for suggestion.
I am sure that there is a good reason, but what prevents you from making
the program just use /etc/hylafax? chrooting?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: deprecating /usr as a standalone filesystem?

[Henrique de Moraes Holschuh]

On Mon, 11 May 2009, Goswin von Brederlow wrote:
> A read-only / should work out of the box just like a read-only /usr. I
> haven't installed a fresh one in a long while though so if you know of
> problems speak up so bugs can be filed and packages can be fixed.

Last time I tried it, /etc was a problem.  I'd have to retry doing it, and
frankly, I do not have the time to muck with that right now.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Jakub Wilk]

* Simon Josefsson , 2009-05-11, 12:55:

+1 for ssmtp

I found ssmtp couldn't cope with mail my various systems were
generating, something about fixed maximum buffer lengths from memory.


Please not ssmtp.  If I recall it correctly I found no way to get it
to send mail to a exim-based smarthost via TLS in a sane way.


What about msmtp?  http://msmtp.sourceforge.net/

AFAIK msmtp does not support local mail delivery.

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Goswin von Brederlow]

Henrique de Moraes Holschuh  writes:

> On Mon, 11 May 2009, Goswin von Brederlow wrote:
>> > A separate /usr *is* the way to go if you don't want any writes in
>> > that filesystem 99.9% of the time (i.e. when you're not doing an
>> > upgrade).
>> 
>> A read-only / does the trick just as well. And if you don't want
>> writes to /usr you probably don't want writes to /bin or /sbin
>> either. So read-only / is really the way to go. Not a strong argument
>> for a seperate /usr.
>
> No, RO / is a lot more difficult to pull off (remember: some of us don't
> want initrds), while RO /usr is really just a three-char change on fstab
> (and if you want apt to remount things automatically, two lines in a config
> file).

Why would you need an initrd for a read-only /?

A read-only / should work out of the box just like a read-only /usr. I
haven't installed a fresh one in a long while though so if you know of
problems speak up so bugs can be filed and packages can be fixed.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Possible mass bug filing: non-doc packages recommending doc packages

[Frank Lin PIAT]

Travis Crump wrote:
> Daniel Burrows wrote:
>> On Fri, May 08, 2009 at 02:58:56PM -0700, Russ Allbery 
>> was heard to say:
 I think that lintian warning is the right way to do it.
>>> I don't -- I think there are too many false positives for a lintian
>>> warning given the thread.  I also think this is fundamentally going in
>>> the wrong direction.  Wouldn't our users expect to get the
>>> documentation
>>> with many of these packages by default?  Normally you do get some
>>> documentation with things, and I've always been surprised by, say, ntp
>>> not including any documentation without installing a separate package.
>>
>>   I agree with this.  I consider installing a program and *not*
>> installing its documentation to be an unusual situation, and if this
>> bug is filed I will treat it as a request to make my packages worse.
>>
>>   aptitude-doc is split out to save archive space and as a feature for
>> users who want to save a few megabytes by removing the user manual, not
>> because I want to force users to jump through hoops to get documentation
>> on their system.
>>
>>   Daniel
>
> If the documentation is something designed to be viewed in a web browser
> and the user has broadband, it is arguably easier to find it on the web.

If the documentation isn't accessible, that should be fixed. (aptidude's
help menu has a link to the text-only version of the documentation,
great).

>  Even knowing precisely where it is[/usr/share/doc/aptitude is it -doc
> or just aptitude, oops I already found it online google aptitude doc
> first result], it is still arguably faster to find it online and once
> you bookmark it is virtually identical.

The documentation published on the web isn't always the same as the version
shipped by Stable.

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: deprecating /usr as a standalone filesystem?

[Henrique de Moraes Holschuh]

On Mon, 11 May 2009, Goswin von Brederlow wrote:
> > A separate /usr *is* the way to go if you don't want any writes in
> > that filesystem 99.9% of the time (i.e. when you're not doing an
> > upgrade).
> 
> A read-only / does the trick just as well. And if you don't want
> writes to /usr you probably don't want writes to /bin or /sbin
> either. So read-only / is really the way to go. Not a strong argument
> for a seperate /usr.

No, RO / is a lot more difficult to pull off (remember: some of us don't
want initrds), while RO /usr is really just a three-char change on fstab
(and if you want apt to remount things automatically, two lines in a config
file).

> The other mount options like nodev or having a different filesystem
> type for /usr are stronger reasons.

They're extra reasons, and strong ones at that, yes.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Simon Josefsson]

Philipp Kern  writes:

> On 2009-05-11, Brian May  wrote:
>> On Fri, May 08, 2009 at 11:31:07PM +0200, Jens Peter Secher wrote:
>>> +1 for ssmtp
>> I found ssmtp couldn't cope with mail my various systems were
>> generating, something about fixed maximum buffer lengths from memory.
>
> Please not ssmtp.  If I recall it correctly I found no way to get it
> to send mail to a exim-based smarthost via TLS in a sane way.

What about msmtp?  http://msmtp.sourceforge.net/

/Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

[RFC] New hylafax package: getting rid of the twin directories structure

[Giuseppe Sacco]

Hi all,
I am packaging the new hylafax version, 6.0. Now that Lenny has been
released I am taking squeeze as base distribution, but I would also give
support to older distribution. Starting from sarge, all users where
strongly advised to update to 2.6 kernel; etch and lenny started
delivering packages that do not work with kernel 2.4. Now I believe that
2.4 kernel is no more supported.

Current hylafax package requires a lot of configuration files in a
specific directory, i.e. /var/spool/hylafax/etc, while Debian keep
configuration files in /etc. So, the init.d script for hylafax, clone
the /etc/hylafax/ directory and copy everything
on /var/spool/hylafax/etc. This is a problem because of duplicated data
and because it require a method to keep both directories in sync.

Keeping all conffiles only in /var/spool/hylafax/etc is against Debian
policy, keeping all of them in /etc/hylafax won't work for hylafax
daemons chrooted in /var/spool/hylafax/. Symbolic links doesn't solve
the problem either.

With 2.6 kernels, we may use the "bind" option in order to mount
a /etc/hylafax on /var/spool/hylafax/etc. So, I am finally moving to
this new configuration, but I have a few concern that I would like to
share, looking for suggestion.

First of all, hylafax package support many configuration: you may start
all daemons from init.d script, or you may have a few othe started via
inittab, or you may have some of them started via inetd. All
configuration may be mixed.

Currently, both directories are kept update by the script
in /etc/init.d. If any daemon is run via inittab or inetd, then they get
only the configuration found in /var/spool/hylafax/etc.

Currently, the main configuration is in /etc/hylafax. Whenever anything
is changed, i.e. using faxadduser, then the command also
update /var/spool/hylafax/etc.

Option 1. The new way, in my opinion, is to check if any daemon is run
via inetd or inittab. If any, then keep the current way. Then check for
mount/bind capability, if not preset, then keep the current way.
Otherwise backup and remove /var/spool/hylafax/etc while *installing*
the new package. Then bind and unbind the new file system when starting
and stopping hylafax using init.d script.

Option 2. do not backup and remove the old directory so, if any daemon
starts via inetd or inittab, they would find a valid configuration. Keep
binding and unbinding from the init.d script even if daemons are run via
inetd or inittab.

Option 3. prompt the user for selecting the preferred way.

Option 4. create an option in /etc/defaults/hylafax to make init.d
script only bind/unbind, without starting/stopping daemon. This could be
useful to people still running daemons via inittab or inetd, but willing
to use the bind/unbind way.

In any case, when this package is installed (not upgraded), follow
Option 1.

Any suggestion?

Thanks,
Giuseppe


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Philipp Kern]

On 2009-05-11, Brian May  wrote:
> On Fri, May 08, 2009 at 11:31:07PM +0200, Jens Peter Secher wrote:
>> +1 for ssmtp
> I found ssmtp couldn't cope with mail my various systems were
> generating, something about fixed maximum buffer lengths from memory.

Please not ssmtp.  If I recall it correctly I found no way to get it
to send mail to a exim-based smarthost via TLS in a sane way.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#528185: ITP: haskell-bzlib -- Haskell bindings to the bzip2 library

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-bzlib
  Version : 0.5.0.0
  Upstream Author : Duncan Coutts 
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib
* License : BSD-style
  Programming Lang: Haskell
  Description : Haskell bindings to the bzip2 library
 .
 This package provides a pure interface for compressing and decompressing
 streams of data represented as lazy ByteStrings. It uses the bz2 C library
 so it has high performance.
 .
 It provides a convenient high level API suitable for most tasks and for the
 few cases where more control is needed it provides access to the full bzip2
 feature set. 
 .
 This package contains the libraries compiled for GHC 6.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Environment variables, debian/rules and dpkg-buildpackage

[Peter Eisentraut]

On Monday 11 May 2009 09:49:31 Raphael Hertzog wrote:
> On Mon, 11 May 2009, Peter Eisentraut wrote:
> > Well, debuild calls dpkg-buildpackage most of the time, unless you give a
> > specific target (which would again possibly be of interest to those who
> > are interested in calling debian/rules by hand for some reason). And that
> > is also something newish.
>
> Any pointer to this feature?

Um, didn't you yourself orginally report this? (bug #476100)  Anyway, the 
current man pages of debuild says this:

"""
An alternative way of using debuild is to use one or more of the parameters 
binary, binary-arch, binary-indep and clean, in which case debuild will 
attempt to gain root  privileges  and then run debian/rules with the given 
parameters.
"""

> > So again some of this would become clearer if the actually supported
> > build methods are more clearly spelled out.  And then if someone could
> > fold all of the functionality of debuild into dpkg-buildpackage, there
> > would be even less distraction and variation.
>
> It's planned, see #476221.

That sounds like the ticket.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Peter Eisentraut]

On Monday 11 May 2009 07:45:02 Manoj Srivastava wrote:
> Changing defaults with a large installed base begs the
>  question: Why?  Random churn for churns sake is not the answer.

But upgrades would (should?) keep exim installed.  A new default would only 
affect new installations.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org