Bug#570919: ITP: python-django-piston -- Piston is a Django mini-framework creating RESTful APIs.

[Michael Ziegler]

Package: wnpp
Severity: wishlist
Owner: Michael Ziegler 


* Package name: python-django-piston
  Version : 0.2.2
  Upstream Author : Jesper Noehr 
* URL : http://bitbucket.org/jespern/django-piston/wiki/Home
* License : BSD
  Programming Lang: Python
  Description : Piston is a Django mini-framework creating RESTful APIs.

 Piston is a relatively small Django application that lets you
 create application programming interfaces (API) for your sites.
 
 It has several unique features:
 
* Ties into Django's internal mechanisms.
* Supports OAuth out of the box (as well as Basic/Digest or custom auth.)
* Doesn't require tying to models, allowing arbitrary resources.
* Speaks JSON, YAML, Python Pickle & XML (and HATEOAS.)
* Ships with a convenient reusable library in Python
* Respects and encourages proper use of HTTP (status codes, ...)
* Has built in (optional) form validation (via Django), throttling, etc.
* Supports streaming, with a small memory footprint.
* Stays out of your way.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100222080512.17401.71988.report...@glint

Bug#570932: ITP: xslthl -- XSLT syntax highlighting

[Mathieu Malaterre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre 


* Package name: xslthl
  Version : 2.0.1
  Upstream Author : Michal Molhanec, Jirka Kosek, Michiel Hendriks
* URL : http://xslthl.sf.net
* License : zlib/libpng License
  Programming Lang: Java
  Description : XSLT syntax highlighting

 This is an implementation of syntax highlighting as an extension module for
 XSLT processors
 .
 Article about programming written in DocBook, code examples can be
 automatically syntax highlighted during the XSLT processing phase. 


-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (500, 'stable'), (200, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100222105708.4686.22534.report...@gotlib.isc.ens-lyon.fr

User uucp to be member of group mail for `sendmail -f'?

[markus schnalke]

I work on bug #409912 [0] in the MTA masqmail currently.

[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409912

See also:
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406395
[2] http://bugs.hylafax.org/show_bug.cgi?id=842

The point is that masqmail allows only root and the group mail to set
the from address (sendmail -f). But the program from hylafax runs as
user uucp.

For exim, this seems to be solved by adjusting the exim configuration:
``[...] you might use trusted_users and add uucp to it [...]'' [3].
See also [4]. It appears that the system administrator has to do the
change in order to enable uucp to call `sendmail -f ...'.

[3] http://pkg-exim4.alioth.debian.org/README/README.Debian.html#id305404
[4] http://lists.debian.org/debian-user/1998/08/msg03182.html


Masqmail does not provide this kind of configuration option. Only one
trusted group can be set up to now.

However, I think the problem could be solved by making the user uucp a
member of group mail. From my limited POV, this solution represents
the logic behind: uucp wants to use special facilities of the MTA,
thus it needs to be in group mail.

Like in exim's case, this change needs an action by the system
administrator. For masqmail, this action could influence other parts
of the system, but if it does, it probably does it the right way.


I request your comments.


meillo


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1njzs9-6lp...@serveme

Re: User uucp to be member of group mail for `sendmail -f'?

[Marco d'Itri]

On Feb 22, markus schnalke  wrote:

> However, I think the problem could be solved by making the user uucp a
> member of group mail. From my limited POV, this solution represents
> the logic behind: uucp wants to use special facilities of the MTA,
> thus it needs to be in group mail.
This does not look right, the purpose of the group mail is allowing the
LDA to lock the mailboxes without running as root and uucp does not 
need anything like this nor it should be able to.
Maybe masqmail just lacks the features needed for this setup.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#570980: man sbin man pages are in section 1 instead of section 8

[jidanni]

Package: general
Severity: wishlist

Many executables in .../sbin have their man pages in section 1 instead
of section 8.

Perhaps a piuparts like script could comb over the apt-file search
results to target them.

Not sure if a policy violation. Or if should be made part of policy.

P.S., I am sure I filed this bug in the right place, as reportbug says
"general General problems (e.g., that many manpages are mode 755)".

P.S.S., Maybe even check if .../bin programs have their man page wrongly put
into section 8 too.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wry5iam9@jidanni.org

Bug#570980: man sbin man pages are in section 1 instead of section 8

[gregor herrmann]

On Mon, 22 Feb 2010 22:54:54 +0800, jida...@jidanni.org wrote:

> Many executables in .../sbin have their man pages in section 1 instead
> of section 8.
> Perhaps a piuparts like script could comb over the apt-file search
> results to target them.

Sounds more like a possible new test for lintian?
 
Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Sting: One World (Not Three) / Love I


signature.asc
Description: Digital signature

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Holger Levsen]

Hi jidanni,

On Montag, 22. Februar 2010, jida...@jidanni.org wrote:
> Many executables in .../sbin have their man pages in section 1 instead
> of section 8.

This is indeed a policy violation as it's covered by policy indirectly via 
FHS:

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREMANMANUALPAGES

> Perhaps a piuparts like script could comb over the apt-file search
> results to target them.

sounds more like a lintian check to me.

> P.S., I am sure I filed this bug in the right place, as reportbug says
> "general General problems (e.g., that many manpages are mode 755)".

I'm tempted to close this bug or reassign to reportbug ;-) IME bugs against 
the general pseudo-package are hardly dealt with, except me trying to get the 
bugs kicked^wreassigned to other packages. 

Had you filed bugs against the individual packages showing this bug, we could 
use them to block 570980 and we could use 570980 to track the the progress.

Do you intend to file individual bugs? I'd appreciate this.


cheers,
Holger



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

Re: Flag images - technical solution

[Osamu Aoki]

Hi,

> On 17/02/2010 19:15, Mike Hommey wrote:
> > On the other hand, one application will want 16x10 icons, another one
> > 24x15, another one may have some effects applied on the flags to better
> > fit the UI design, etc.
> > 
> > So while applications amy be using flags already, are they really using
> > the same ones, and would they benefit from having only one source for
> > all flags ?

Quoting Dmitry E. Oboukhov (un...@debian.org):
> May be the size must be included into path?
> 
> like
> flags/countires//16x10/
> flags/countires//24x15/

On Wed, Feb 17, 2010 at 07:28:56PM +0100, Jérémy Lal wrote:
> Maybe SVG flags would address this issue ?
> 
> Also when it's not possible to choose between two flags, one could imagine
> just providing an icon with the 2 or 3-letter country code in it, and no flag.

I guess, there should be coordinated technical solution in which each
package install things like
  flags/24x15/.png
  flags/16x10/.png
  flags/scalable/.svg

For some selectable locale-id, multiple icons
  flags/24x15/.variant-0.png 
 (Nothing but 2 or 3-letter country code in it)
  flags/24x15/.variant-1.png (Flag choice #1)
  flags/24x15/.variant-2.png (Flag choice #2)

Then 
  flags/24x15/.png
is managed via alternative system to point to one of the choices above.

(I know alternative is not good idea for installer, ...)

This should make things easy to impliment icon across application
without political issues, someday if someone bothers to do this.

Osamu

PS: Taiwan's reference in the public life has been moving target.  The
new president Ma of Taiwan seems to use interesting new wordings... when
he represents him to the mainland.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100222155000.ga6...@osamu.debian.net

Bug#570980: man sbin man pages are in section 1 instead of section 8

[Emilio Pozuelo Monfort]

On 22/02/10 15:54, jida...@jidanni.org wrote:
> Many executables in .../sbin have their man pages in section 1 instead
> of section 8.
> 
> Perhaps a piuparts like script could comb over the apt-file search
> results to target them.

This could rather be a lintian check.

Emilio



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b82ab61.2060...@debian.org

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[jidanni]

HL> Do you intend to file individual bugs? I'd appreciate this.

Actually I've filed many individual bugs, some even just today.

Then I got this great idea that instead of me just mentioning in to
packages that I've stumbled into, there could be a systematic combing of
all Debian.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874ol9fcno@jidanni.org

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Sandro Tosi]

On Mon, Feb 22, 2010 at 17:07, Holger Levsen  wrote:
>> P.S., I am sure I filed this bug in the right place, as reportbug says
>> "general General problems (e.g., that many manpages are mode 755)".
>
> I'm tempted to close this bug or reassign to reportbug ;-)

Please don't.

> IME bugs against
> the general pseudo-package are hardly dealt with, except me trying to get the
> bugs kicked^wreassigned to other packages.

The one above is the description of 'general' we retrieve from
[1], that's the canonical place for definition of pseudo-packages and
their description.

[1] http://bugs.debian.org/pseudopackages/pseudo-packages.description

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/8b2d7b4d1002220846o68347350u48b99cc924129...@mail.gmail.com

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Holger Levsen]

Hi jidanni,

On Montag, 22. Februar 2010, jida...@jidanni.org wrote:
> Then I got this great idea that instead of me just mentioning in to
> packages that I've stumbled into, there could be a systematic combing of
> all Debian.

Can you point me to bugs about manpages in section 1 which belong in section 
8? Else I'll just reassign this bug to lintian and leave it to the individual 
maintainers to fix their packages.


cheers,
Holger



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

Re: correct/ideal way to obtain root from a shell script

[Bill Allombert]

On Wed, Feb 10, 2010 at 11:45:20AM +, Jon Dowland wrote:
> On Mon, Feb 01, 2010 at 08:37:57PM +0100, Bill Allombert wrote:
> > Simply depends on the menu package which provide su-to-root
> 
> We've determined that su-to-root in it's current state
> doesn't handle the disabled-root case anyway, so this
> wouldn't win me anything.

This issue is not specific to su-to-root: gksu has the same problem:
you have to change the gconf key /apps/gksu/sudo-mode to use sudo mode.
However, once you have done that, su-to-root -X will also work, since
it will call gksu.

In the case of text-mode su-to-root, maybe su-to-root can call
gconftool -g /apps/gksu/sudo-mode
to see whether it should use sudo instead of su.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100222164322.ge27...@yellowpig

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Holger Levsen]

Hi Sandro,

please don't cc: me, I'm subscribed.

On Montag, 22. Februar 2010, Sandro Tosi wrote:
> > I'm tempted to close this bug or reassign to reportbug ;-)
> Please don't.

Neither? ;)

> The one above is the description of 'general' we retrieve from
> [1], that's the canonical place for definition of pseudo-packages and
> their description.
>
> [1] http://bugs.debian.org/pseudopackages/pseudo-packages.description

hmm.. not sure with what to replace this example with perm 755... but noticed 
that "Base system general bugs" for base is also sub-optimal. At least the 
word "general" should be removed there.. 

But in general (pun intended) I wonder if its still useful to have a base and 
a general pseudo�ackage.  IMO  one of the two would  be sufficiient.


cheers,
Holger


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

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[jidanni]

I tried to find all bugs with "section 8" in their title via 
http://bugs.debian.org
   An error occurred. Error was: You have to choose something to select by
I'll try this to at least find (most of) mine:
$ w3m -cols  -dump 
http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=jida...@jidanni.org|grep 
-i section\ 8
  • #476403 [w|  |  ] [powermgmt-base] section 8 of manual
  • #512447 [w|  |  ] [libgraphviz4] man page belongs in section 8
  • #512449 [w|  |  ] [powermgmt-base] man page belongs in section 8
  • #512450 [w|  |  ] [util-linux] man page belongs in section 8
  • #512451 [w|  |  ] [wodim] man page belongs in section 8
  • #512452 [w|  |  ] [xjdic] man page belongs in section 8
  • #570980 [w|  |  ] [general] man sbin man pages are in section 1 instead of 
section 8
  • #570981 [w|  |  ] [aircrack-ng] perhaps move man pages to section 8
  • #566219 [w|  |↝] [unetbootin] move to section 8 and sbin
Yes, perhaps reassign to lintian.



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vddpdx5c@jidanni.org

Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Holger Levsen]

clone 570991 -1
reassign -1 lintian
retitle -1 "please add a check against commands in /sbin using section 1 
manpages"
severity -1 wishlist
block 570991 by 476403
block 570991 by 512447
block 570991 by 512449
block 570991 by 512450
block 570991 by 512451
block 570991 by 512452
block 570991 by 570980
block 570991 by 570981
block 570991 by 566219
thanks



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

Re: Bug#570980: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Adam D. Barratt]

# Cc to -devel for information after the reassign
merge 570980 348864
thanks

Holger Levsen wrote, Monday, February 22, 2010 5:19 PM

clone 570991 -1
reassign -1 lintian
retitle -1 "please add a check against commands in /sbin using section 1 
manpages"


fwiw, there *was* such a lintian check, which was removed as the section 1/8 
division is not exactly the same as the bin/sbin division. At least last 
time I can find it being discussed, the man-db maintainer agreed with not 
having the check (see #348864, with which I've just merged this bug).


In fact, that log appears to include a piuparts maintainer arguing that 
piuparts(1) is correct despite the program being in /sbin. ;-)


Regards,

Adam 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a1f30f3718324e178245fddf8eefa...@internal.avcosystems.com

Processed: Re: reportbug general bug filing recommendation (was Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Debian Bug Tracking System]

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

> clone 570991 -1
Bug#570991: tuxtype: Package with doc/AUTHORS and doc/ChangeLog and doc/TODO
Bug 570991 cloned as bug 570994.

> reassign -1 lintian
Bug #570994 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Bug reassigned from package 'tuxtype' to 'lintian'.
Bug No longer marked as found in versions tuxtype/1.8.0-1.
> retitle -1 "please add a check against commands in /sbin using section 1 
> manpages"
Bug #570994 [lintian] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Changed Bug title to '"please add a check against commands in /sbin using 
section 1 manpages"' from 'tuxtype: Package with doc/AUTHORS and doc/ChangeLog 
and doc/TODO'
> severity -1 wishlist
Bug #570994 [lintian] "please add a check against commands in /sbin using 
section 1 manpages"
Severity set to 'wishlist' from 'minor'

> block 570991 by 476403
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was not blocked by any bugs.
Added blocking bug(s) of 570991: 476403
> block 570991 by 512447
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 476403
Added blocking bug(s) of 570991: 512447
> block 570991 by 512449
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 476403 512447
Added blocking bug(s) of 570991: 512449
> block 570991 by 512450
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 476403 512447
Added blocking bug(s) of 570991: 512450
> block 570991 by 512451
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 476403 512447 512450
Added blocking bug(s) of 570991: 512451
> block 570991 by 512452
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 476403 512447 512451 512450
Added blocking bug(s) of 570991: 512452
> block 570991 by 570980
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 512452 476403 512447 512451 512450
Added blocking bug(s) of 570991: 570980
> block 570991 by 570981
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 570980 512449 476403 512452 512447 512451 512450
Added blocking bug(s) of 570991: 570981
> block 570991 by 566219
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 570980 512452 476403 570981 512447 512451 512450
Added blocking bug(s) of 570991: 566219
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.126685919029065.transcr...@bugs.debian.org

Processed (with 1 errors): Fix cloning of section 1 manpages bug to lintian

[Debian Bug Tracking System]

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

> # wrong bug was cloned
> close 570994
Bug#570994: "please add a check against commands in /sbin using section 1 
manpages"
'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing.
Bug closed, send any further explanations to Osamu Aoki 

> # clone proper bug
> clone 570980 -1
Bug#570980: man sbin man pages are in section 1 instead of section 8
Bug 570980 cloned as bug 570998.

> reassign -1 lintian
Bug #570998 [general] man sbin man pages are in section 1 instead of section 8
Bug reassigned from package 'general' to 'lintian'.
> retitle -1 please add a check against commands in /{usr/,}sbin using
Bug #570998 [lintian] man sbin man pages are in section 1 instead of section 8
Changed Bug title to 'please add a check against commands in /{usr/,}sbin 
using' from 'man sbin man pages are in section 1 instead of section 8'
> section 1 manpages
Unknown command or malformed arguments to command.

> severity -1 wishlist
Bug #570998 [lintian] please add a check against commands in /{usr/,}sbin using
Ignoring request to change severity of Bug 570998 to the same value.
> block 570980 by 476403
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was not blocked by any bugs.
Added blocking bug(s) of 570980: 476403
> block 570980 by 512447
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 476403
Added blocking bug(s) of 570980: 512447
> block 570980 by 512449
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 476403 512447
Added blocking bug(s) of 570980: 512449
> block 570980 by 512450
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 476403 512447
Added blocking bug(s) of 570980: 512450
> block 570980 by 512451
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 476403 512447 512450
Added blocking bug(s) of 570980: 512451
> block 570980 by 512452
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 476403 512447 512451 512450
Added blocking bug(s) of 570980: 512452
> block 570980 by 570981
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 512452 476403 512447 512451 512450
Added blocking bug(s) of 570980: 570981
> block 570980 by 566219
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 476403 512452 570981 512447 512451 512450
Added blocking bug(s) of 570980: 566219
> block 570980 by -1
Bug #570980 [general] man sbin man pages are in section 1 instead of section 8
Was blocked by: 512449 512452 476403 570981 512447 512451 512450 566219
Added blocking bug(s) of 570980: 570998
> # remove incorrect blocking tags
> unblock 570991 by 476403
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 476403 512447 512449 512450 512451 512452 566219 570980 570981 
570998
Removed blocking bug(s) of 570991: 476403
> unblock 570991 by 512447
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 512451 570980 512452 570981 570998 512447 512450 566219
Removed blocking bug(s) of 570991: 512447
> unblock 570991 by 512449
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512449 512451 570980 512452 570981 570998 512450 566219
Removed blocking bug(s) of 570991: 512449
> unblock 570991 by 512450
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512451 570980 512452 570981 570998 512450 566219
Removed blocking bug(s) of 570991: 512450
> unblock 570991 by 512451
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 512451 570980 512452 570981 570998 566219
Removed blocking bug(s) of 570991: 512451
> unblock 570991 by 512452
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 570980 512452 570981 570998 566219
Removed blocking bug(s) of 570991: 512452
> unblock 570991 by 570981
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 570980 570981 570998 566219
Removed blocking bug(s) of 570991: 570981
> unblock 570991 by 570980
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 570980 570998 566219
Removed blocking bug(s) of 570991: 570980
> unblock 570991 by 566219
Bug #570991 [tuxtype] tuxtype: Package with doc/AUTHORS and doc/ChangeLog and 
doc/TODO
Was blocked by: 570998 566219
Removed blocking bug(s) of 570991: 566219
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email

Re: User uucp to be member of group mail for `sendmail -f'?

[Florian Weimer]

* markus schnalke:

> For exim, this seems to be solved by adjusting the exim configuration:
> ``[...] you might use trusted_users and add uucp to it [...]'' [3].
> See also [4]. It appears that the system administrator has to do the
> change in order to enable uucp to call `sendmail -f ...'.

Debian's Exim configuration honors -f for all users by default.  After
all, you can just inject the message via localhost:smtp anyways.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878walhz0e@mid.deneb.enyo.de

Re: Bug#570980: man sbin man pages are in section 1 instead of section 8

[Russ Allbery]

gregor herrmann  writes:
> On Mon, 22 Feb 2010 22:54:54 +0800, jida...@jidanni.org wrote:

>> Many executables in .../sbin have their man pages in section 1 instead
>> of section 8.
>> Perhaps a piuparts like script could comb over the apt-file search
>> results to target them.

> Sounds more like a possible new test for lintian?

There's already an open bug for it, with some possible issues and false
positive problems noted there (although nothing that rules out the
implementation at least in a limited form).

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87635pm6it@windlord.stanford.edu

Re: FORTRAN implementation in Lenny

[kamaraju kusumanchi]

>    ]$ f95 -O3 -lm -march=nocona -o nbody.x nbody.f90
>    ]$ time ./nbody.x 5000
>         Energy 0: -0.169075164
>         Energy 1: -0.169059907
>         Elapsed time: 2m 31.7s
>

AFAIK, the GNU fortran compiler goes with the name gfortran (not f95).
Please give the output of "gfortran -v"  so that we will know the
exact options you are using.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1d9315cf1002221427w12bb4987wc91eec77dd118...@mail.gmail.com

Bug#571031: ITP: ats-lang-anairiats -- The ATS language compiler Anairiats

[Matthew Danish]

Package: wnpp
Severity: wishlist
Owner: Matthew Danish 

* Package name: ats-lang-anairiats
  Version : 0.1.7
  Upstream Author : Hongwei Xi 
* URL : http://www.ats-lang.org/
* License : GPL-3 and LGPL-2.1
  Programming Lang: ATS, C
  Description : The ATS language compiler Anairiats

 ATS is a programming language with a highly expressive type system
 rooted in the framework Applied Type System. In particular, both
 dependent types and linear types are available in ATS. The current
 implementation of ATS (ATS/Anairiats) is written in ATS itself. It
 can be as efficient as C/C++ and supports a variety of programming
 paradigms.
 .
 In addition, ATS contains a component ATS/LF that supports a form of
 (interactive) theorem proving, where proofs are constructed as total
 functions. With this component, ATS advocates a programming style
 that combines programming with theorem proving. Furthermore, this
 component may be used as a logical framework to encode various
 deduction systems and their (meta-)properties.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2010021334.28606.18503.report...@andante.bu.edu

Bug#570980: teasers

[jidanni]

Well just like many of the comments to 348864, I just hate the "teasers"
in section 1 that only root can run.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wry4vou6.fsf...@jidanni.org

Bug#571041: ITP: dreampie -- advanced Python shell

[Luca Falavigna]

Package: wnpp
Owner: Luca Falavigna 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: dreampie
  Version : 1.0
  Upstream Author : Noam Yorav-Raphael 
* URL : http://dreampie.sourceforge.net
* License : GPLv3 and others
  Programming Lang: Python
  Description : advanced Python shell

This Python shell permits to work in a more productive way with Python
interpreter providing features not yet implemented in standard IDLE.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223004811.4a7e2...@utumno

Re: Bug#571041: ITP: dreampie -- advanced Python shell

[Neil McGovern]

On Tue, Feb 23, 2010 at 12:48:11AM +0100, Luca Falavigna wrote:
>   Description : advanced Python shell
> 
> This Python shell permits to work in a more productive way with Python
> interpreter providing features not yet implemented in standard IDLE.
> 

This short and long description need quite a bit of work. May I suggest
debian-l10n-engl...@lists.debian.org if you need some help?

Neil
-- 
* stockholm bangs head against budget
 outsch
 h01ger: it is still very soft, i did not hurt myself
 stockholm: But you bled on the budget, and now it's red again!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223003345.gy22...@halon.org.uk

Re: FORTRAN implementation in Lenny

[Mark Allums]

On 2/21/2010 10:28 PM, Mark Allums wrote:

On 2/21/2010 4:44 PM, Fuentes, Adolfo wrote:

]$ gcc -O3 -lm -march=nocona -o nbody.x nbody.c
]$ time ./-o nbody.x 5000
Energy 0: -0.169075164
Energy 1: -0.169059907
Elapsed time: 1m 17.4s

]$ f95 -O3 -lm -march=nocona -o nbody.x nbody.f90
]$ time ./nbody.x 5000
Energy 0: -0.169075164
Energy 1: -0.169059907
Elapsed time: 2m 31.7s

]$ g95 -O3 -lm -march=nocona -o nbody.x nbody.f90
]$ time ./nbody.x 5000
Energy 0: -0.169075164
Energy 1: -0.169059907
Elapsed time: 1m 40.3s



gcc is "highly"* optimized, the g95 compiler would have similar
optimizations, because they share back ends. The Intel compiler should
beat it, however, if you are very familiar with Intel architecture, and
are willing to learn the ins and outs. I'm not personally acquainted
with other compilers, so can't answer questions about them.

(And my FORTRAN days are behind me. I can only answer in these general
terms. I hope someone else can be more specific.)

Hope this helps,

Mark Allums



I just realized that I have confused GNU FORTRAN with something else. 
What is g95?


Disregard the above.  Carry on.

Mark Allums


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b832ad6.9030...@allums.com

Bug#570980: man sbin man pages are in section 1 instead of section 8

[Raphael Geissert]

#348864 ...
-- 
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201002221916.54574.atom...@gmail.com

Re: Re: Google Summer of Code 2009: Debian's Shortlist

[Filipus Klutiero]

> On 2009-04-11, Filipus Klutiero  wrote:
> > Obey Arthur Liu wrote:
> >> === And the details: ===
> >
> > [...]
> > These descriptions are very short. Assuming these are the abstracts,
> > that's not the students' fault. The abstracts were shortened this year
> > to 500 characters. I struggled to shorten mine to fit this. At this
> > length, it's probably impossible to fit a decent summary of most
> > projects. It would normally make sense to use abstracts for this use
> > case. Maybe Google should be asked to change the limit. Otherwise I'd
> > like to see a custom description which describes a little further. I
> > currently can't comment on all projects presented.
> > That said, this shortlist remains useful, and I thank you for this great
> > jump in transparency.
>
> Mind to tell us what your proposed project was?  For more transparency?
>
> Kind regards,
> Philipp Kern

Here is my application, stripped only from the personal section. I will not 
submit this idea anymore. Students should feel free to use this application as 
they wish. The project needs a student with a good understanding of Debian 
package management. Most importantly, a mentor familiar with APT should be 
found. This was a very scarce resource in the last 3 years.


= Project Title =
Improved package management of language packs

= Origins =
There are currently two methods to distribute localized data:
* Bundling localized data for all languages with the application package. The 
main issue with this approach is the size of the package.
* Architecture-independent packages associated with the application packages 
providing localized data. There is typically one package per language. Since 
they 'enable' the language translation for that software when installed they 
are called language packages or language packs. The main issue with this 
approach is that the language package for an application is not installed 
automatically.

The first method is suboptimal while the second is less usable.

For more information, see 
http://wiki.debian.org/i18n/TranslationDataDistribution/Chealer

= Project =
The intention is to optimize distribution of localized data by improving the 
usability of the second method, which should encourage its use and diminish 
the usage of the first method.

Concretely, the first goal is that installation of language packs happens 
automatically. For example, French people should get openoffice.org-l10n-fr 
installed automatically when openoffice.org is installed.

The second goal is to control the effects of growing the number of packages. 
The growth of the Packages file and the number of packages returned by searches 
should be avoided or limited.

= Benefits to Debian =

The Debian groups which would benefit from this project are users and mirror 
providers. Administrators of non-English systems are particularly targeted.

== Direct benefits (improvements to language packs handling) ==
The first direct benefit to users is that administrators will no longer need to 
specifically select the language packages they want to install in order to make 
translations available.
The second direct benefit is that the size of Packages and the number of 
packages matching a search should be reduced. Note that the actual secondary 
direct benefits will depend on how exactly controlling the effects of growing 
the number of packages will be done.

== Indirect benefits (avoiding packages bundling l10n data) ==
The indirect benefit of this project is that increasing the interest in 
language packs should reduce the number of application packages bundling 
localized data. Concretely, the issues of this method will be avoided:

 * Localized data increases (for all architectures) the binary package size.
  * On multi-architecture mirrors, architecture-specific packages increase disk 
usage and bandwidth usage for synchronizations.
  * Increases bandwidth usage for users and uploading mirrors.
  * Increases disk space usage for users. localepurge, considered a hack, 
exists to diminish this issue.
  * Time for installs is increased due to getting and unpacking a larger .deb.
 * Localized data is in the same binary package and therefore has to be built 
from the same source package as the application.
  * Localized data can not be handled by different maintainers.
  * Translation updates can not be made independently from the application 
binary package and could cause a regression in the application package. It is 
risky to do translation updates during a freeze.
  * A translation update means that the application binary package needs to be 
rebuilt. This causes larger updates (mostly more bandwidth usage) and 
increased buildd usage, so maintainers tend to wait for a new software release 
before providing the translation updates. The delay for translator's work to 
reach users tends to increase (e.g. debconf updates sitting in the BTS).

Work from maintainers will be needed to obtain these indirect benefits. 
Nevertheless, I expe

Re: Changes in dpkg Pre-Depends

[Guillem Jover]

On Sat, 2010-02-20 at 10:07:45 +0100, Stefano Zacchiroli wrote:
> On Sat, Feb 20, 2010 at 12:15:10AM +0100, Guillem Jover wrote:
> > Second, I'd like to switch from statically to dynamically linking
> > against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
> > and libselinux (affecting dpkg itself only on Linux). Here's the
> > arguments I know of against and in favour, with rebuttals:
> 
> I'm personally convinced by your arguments. Still, I'd like if you
> consider the transitional idea of having---say, for a release---two
> different binary packages shipping dpkg: "dpkg" (essential: yes) and
> "dpkg-static" (essential: no), the latter containing a fully statically
> linked version of dpkg, coming as /usr/bin/dpkg-static.
> 
> I've seen this for other safety-critical tools, e.g. the dar backup tool
> which comes both as "dar" and "dar-static". I personally don't believe
> there would be *much* use of "dpkg-static", but having it around for a
> release would enable to see if/how many (paranoid) people actually
> install it. Would that make sense in your opinion? Would it be worth?

I don't think this would be worth it, as Marco has also said, if the
system is hosed but you can still get to the point of obtaining a
package to install you might as well just obtain the broken files.
Of course you might have it already on apt's cache, but that's not
usually the case when you need it. :)

Also I'm guessing if it's there some people will end up installing it,
either on purpose or by accident, and trying to remove it later might
find some resistance (from the former).

Something that came to me after having sent the mail is that we have
programs way more critical that are dynamically linking with all used
libraries, like the ones involved in the boot sequence: init (libc,
libsepol, libselinux), mount (libc, libblkid, libuuid, libsepol,
libselinux), udevd (libc, libselinux) and there's not been the need
to provide static versions for them, and I would tend to think an
unbootable system is trickier to recover than one where you cannot
install new packages.

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223042013.gb29...@gaara.hadrons.org

Re: Changes in dpkg Pre-Depends

[Guillem Jover]

On Sat, 2010-02-20 at 00:15:10 +0100, Guillem Jover wrote:
> First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,
> the latter is a bit bigger in size (lzma 172 KiB; xz-utils 504 KiB,
> 160 KiB in share/doc/ and liblzma2 304 KiB, 124 KiB in share/doc/)

Regarding xz-utils' size, I was just checking and it seems not all
programs are linking against liblzma, by passing --enable-dynamic to
both configure lines the package gets reduced to 396 KiB. Also by
not shipping xzdec and lzmadec the package gets down to 324 KiB.

Jonathan, any reason why those are not dynamically linked? Also what's
the point of shipping the xzdec and lzmadec tools in the main package?
It seems they would make sense as part of another package as tiny
decompressors-only, but no in addition to the main tools as those
already provide the whole functionality?

thanks,
guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223044512.gc29...@gaara.hadrons.org

Re: Changes in dpkg Pre-Depends

[Jonathan Nieder]

Guillem Jover wrote:

> Regarding xz-utils' size, I was just checking and it seems not all
> programs are linking against liblzma, by passing --enable-dynamic to
> both configure lines the package gets reduced to 396 KiB. Also by
> not shipping xzdec and lzmadec the package gets down to 324 KiB.
> 
> Jonathan, any reason why those are not dynamically linked?

The usual i386-centric reason: the PIC version is (~5%) slower than
the non-PIC version.  See PACKAGERS in the source, section 4.1.
I considered doing this only on i386, but since I only have an i386 to
test on, I would worry about missing packaging bugs.

I could very easily be convinced to switch to dynamic linking.  Please
file a bug (with what you just said about size and any other reasons).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223050612.ga8...@progeny.tock

Bug#571060: xz-utils: give xzdec and lzmadec their own package

[Jonathan Nieder]

Package: xz-utils
Version: 4.999.9beta+20100212-1
Severity: wishlist

Guillem Jover wrote:

> Also what's
> the point of shipping the xzdec and lzmadec tools in the main package?
> It seems they would make sense as part of another package as tiny
> decompressors-only, but no in addition to the main tools as those
> already provide the whole functionality?

Indeed.

xzdec and lzmadec are meant mostly for copying to small media with
lots of xz- or lzma-compressed files (for distribution).  They don’t
belong in the xz-utils package, so let’s move them.

Thanks,
Jonathan



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223051026.gb8...@progeny.tock

Re: Changes in dpkg Pre-Depends

[Robert Collins]

On Tue, 2010-02-23 at 05:20 +0100, Guillem Jover wrote:

> I don't think this would be worth it, as Marco has also said, if the
> system is hosed but you can still get to the point of obtaining a
> package to install you might as well just obtain the broken files.
> Of course you might have it already on apt's cache, but that's not
> usually the case when you need it. :)

dpkg is useful for more than just installing new packages; a hosed
system might be fixed by removing a package, running maintainer scripts,
both of which dpkg is the right tool for.

Not arguing for or against, just noting that you're being overly
restrictive in your analysis of what a sdpkg might be used for.

-Rob


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

Re: Changes in dpkg Pre-Depends

[Don Armstrong]

On Sat, 20 Feb 2010, Guillem Jover wrote:
> First, I'd like to change the dpkg Pre-Depends from lzma to xz-utils,

[...]

> Second, I'd like to switch from statically to dynamically linking
> against zlib and libbz2, eventually liblzma too (affecting dpkg-deb)
> and libselinux (affecting dpkg itself only on Linux). Here's the
> arguments I know of against and in favour, with rebuttals:

[...]
 
> So if there's no strong reason not to, I'd like to do these changes
> for next dpkg 1.15.6 release. Note though that they are not
> interdependent, and if we decided so, one could be done while not
> the other.

I don't have any objections to this, but I'd strongly suggest that
this get a run-through experimental with an announcement on
-devel-announce to request testing so that any really bad problems are
caught before it gets deployed more widely.


Don Armstrong

-- 
Who is thinking this?
I am.
 -- Greg Egan _Diaspora_ p38

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100223065155.gd3...@rzlab.ucr.edu

Re: Bug#571041: ITP: dreampie -- advanced Python shell

[David Paleino]

Luca Falavigna wrote:

> Package: wnpp
> Owner: Luca Falavigna 
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
>
> * Package name: dreampie
>   Version : 1.0
>   Upstream Author : Noam Yorav-Raphael 
> * URL : http://dreampie.sourceforge.net
> * License : GPLv3 and others
>   Programming Lang: Python
>   Description : advanced Python shell
>
> This Python shell permits to work in a more productive way with Python
> interpreter providing features not yet implemented in standard IDLE.

It would be cool if you included in the long description what dreampie
does that python/idle/ipython/bpython don't do :)

David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 |
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/hlvv8m$g4...@dough.gmane.org

RE: FORTRAN implementation in Lenny

[Fuentes, Adolfo]

Hello Raju.

 is a link in "/etc/alternatives" to "/usr/bin/gfortran".

When typing "gfortran -v" the options are:

]$ gfortran -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' 
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld 
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu 
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1) 


---
Department of Chemistry -- Surface Science Research Centre
University of Liverpool
Crown Street
Liverpool, L69 7ZD
United Kingdom

"Treat the Earth well. It was not given to you by your parents, it was loaned 
to you by your children." (Ancient native American Indian proverb)

From: kamaraju kusumanchi [raju.mailingli...@gmail.com]
Sent: 22 February 2010 22:27
To: Fuentes, Adolfo
Cc: debian-u...@lists.debian.org; debian-devel@lists.debian.org; 
debian-resea...@lists.debian.org; debian-scie...@lists.debian.org
Subject: Re: FORTRAN implementation in Lenny

>]$ f95 -O3 -lm -march=nocona -o nbody.x nbody.f90
>]$ time ./nbody.x 5000
> Energy 0: -0.169075164
> Energy 1: -0.169059907
> Elapsed time: 2m 31.7s
>

AFAIK, the GNU fortran compiler goes with the name gfortran (not f95).
Please give the output of "gfortran -v"  so that we will know the
exact options you are using.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/debb97ea3eef8e489b88cefa9b3f36e255f22e6...@staffmbx2.livad.liv.ac.uk