Bug#658086: ITP: libstring-toidentifier-en-perl -- module to convert strings to English program identifiers

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libstring-toidentifier-en-perl
  Version : 0.06
  Upstream Author : Rafael Kitover 
* URL : http://search.cpan.org/dist/String-ToIdentifier-EN/
* License : perl like
  Programming Lang: Perl
  Description : module to convert strings to English program identifiers

String::ToIdentifier::EN is a Perl module that provides a utility to
convert an arbitrary string into an identifier usable in a computer
program. The intent is to make unique identifier names from which the
content of the original string can be easily inferred by a human just
by reading the identifier.

If you need the full set of alphanumeric caracters including Unicode,
see the subclass String::ToIdentifier::EN::Unicode.

Currently, this process is one way only, and will likely remain this way.

This module is a dependency of newest libdbix-class-loader-perl

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/




-- 
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/201201311031.15552@debian.org

Re: Bug#604947: midish: diff for NMU version 1.0.4-1.1

[Alexander Reichle-Schmehl]

[ droping the bug logs from CC, adding -devel in case further discussion
is needed ]

Hi Konstantinos!

Am 31.01.2012 13:51, schrieb Konstantinos Margaritis:

> I've prepared an NMU for midish (versioned as 1.0.4-1.1) and
[..]

+midish·(1.0.4-1.1)·unstable;·urgency=low
+
+··*·Non-maintainer·upload,·fixes·FTBFS.·(Closes:·#604947,·#652177)
+
+·--·Konstantinos·Margaritis···Tue,·31·Jan·2012·00:44:29·+



I'm not the maintainer but nevertheless I'd like to comment on that
changelog entry:  Please be more verbose on what you actually changed.
Without taking a look at the bug reports one barely knows what the
problem was and without taking a deeper look into the debdiff, what you
actually did to solve the problem is a mystery.

Also it would IMHO be appropriate to thank the submitter of a patch,
when uploading his/her patch in changelog.


Best regards,
  Alexander


-- 
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/4f27b844.9080...@debian.org

Re: alioth is down (again)

[Peter Palfrader]

On Die, 31 Jän 2012, Paul Wise wrote:

> On Tue, Jan 31, 2012 at 2:58 AM, Julien Cristau wrote:
> 
> > Like ldapsearch(1)?  That kind of already exists...
> 
> More like a frontend to ldapsearch that doesn't require people to know
> about LDAP, about the Debian schema, nor ldapsearch itself.

The status field in ldap unfortunately isn't really all that well
maintained, and therefore not too useful.

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120131094958.gb7...@anguilla.noreply.org

Re: Bug#604947: midish: diff for NMU version 1.0.4-1.1

[Konstantinos Margaritis]

Hi Alexander,

On Tuesday 31 January 2012 11:45:40 Alexander Reichle-Schmehl wrote:
> I'm not the maintainer but nevertheless I'd like to comment on that
> changelog entry:  Please be more verbose on what you actually changed.
> Without taking a look at the bug reports one barely knows what the
> problem was and without taking a deeper look into the debdiff, what you
> actually did to solve the problem is a mystery.

No disagreement there, I plan to do a few more NMUs [1], so I'll take your 
advice into account in those. In these particular case though, the fix was 
pretty trivial, but yes you are right, I should be more verbose.

> Also it would IMHO be appropriate to thank the submitter of a patch,
> when uploading his/her patch in changelog.

Again, good point. Thanks for the tips.

Regards

Konstantinos

[1] http://wiki.debian.org/NMUs_armhf_January2012 not all are armhf related, 
but some are RC bugs since October, which I find a bit annoying.


-- 
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/201201311202.59081.mar...@debian.org

Bug#658109: ITP: libsvn-class-perl -- manipulate Subversion workspaces with Perl objects

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libsvn-class-perl
  Version : 0.17
  Upstream Author : Peter Karman 
* URL : http://search.cpan.org/dist/SVN-Class/
* License : Perl like
  Programming Lang: Perl
  Description : manipulate Subversion workspaces with Perl objects

SVN::Class extends Path::Class to allow for basic Subversion workspace
management. SVN::Class::File and SVN::Class::Dir are subclasses of
Path::Class::File::Stat and Path::Class::Dir respectively.

SVN::Class does not use the SVN::Core Subversion SWIG bindings. Instead, the
svn binary tool is used for all interactions, using IPC::Cmd. This design
decision was made for maximum portability and to eliminate non-CPAN
dependencies.

This module is a dependency of libpadre-plugin-svn-perl

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/




-- 
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/201201311333.36531@debian.org

Bug#658115: ITP: fxt -- Multithreaded tracing library

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: fxt
  Version : 0.2.3
  Upstream Author : Samuel Thibault 
* URL : http://www.example.org/
* License : GPL
  Programming Lang: C
  Description : Multithreaded tracing library

 FxT is a library and associated tools that can be used to analyze the
 performance of multithreaded programs which can potentially use a
 hybrid thread scheduler (i.e. a user-level scheduler on top of a
 kernel-level one). The Marcel thread library can take full profit from
 this library.

 FxT is based on the offline analysis of traces (sequence of events recorded at
 run time).




-- 
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/20120131125724.ga14...@type.bordeaux.inria.fr

Re: Proposed mass bug-filing/NMUing: perl 4 libraries

[Colin Watson]

On Mon, Jan 30, 2012 at 07:18:25PM +, Dominic Hargreaves wrote:
> Colin Watson 
>info2man

This had been filed as #652499, but I'd been holding off uploading the
fix while I figured out a problem with some horrible elderly code that
caused info2man to do nothing useful at all with modern versions of
Perl.  I've fixed that now and uploaded.

-- 
Colin Watson   [cjwat...@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/20120131130126.ga6...@riva.dynamic.greenend.org.uk

Bug#658116: ITP: eztrace -- Automatic execution trace generation for HPC

[Samuel Thibault]

Package: wnpp
Severity: wishlist
Owner: Samuel Thibault 

* Package name: eztrace
  Version : 0.3
  Upstream Author : Francois Trahay 
* URL : http://eztrace.gforge.inria.fr/
* License : GPL
  Programming Lang: C
  Description : Automatic execution trace generation for HPC

EZTrace is a tool that aims at generating automatically execution traces
from HPC (High Performance Computing) programs. It generates execution
trace files that can be interpreted by visualization tools such as
ViTE. It uses LD_PRELOAD and dlsym() to intercept calls to the usual HPC
primitives, to be observed.



-- 
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/20120131130024.ga14...@type.bordeaux.inria.fr

Bug#658130: ITP: libmoosex-markasmethods-perl -- moose extension to ark overload code symbols as methods

[Dominique Dumont]

Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmoosex-markasmethods-perl
  Version : 0.14
  Upstream Author : Chris Weyl 
* URL : http://search.cpan.org/dist/MooseX-MarkAsMethods/
* License : GPL-2
  Programming Lang: Perl
  Description : moose extension to ark overload code symbols as methods

MooseX::MarkAsMethods is a Perl module that allows one to easily mark
certain functions as Moose methods. This will allow other packages
such as namespace::autoclean to operate without blowing away your
overloads. After using MooseX::MarkAsMethods your overloads will be
recognized by Class::MOP as being methods, and class extension as well
as composition from roles with overloads will "just work".

By default we check for overloads, and mark those functions as methods.

If 'autoclean => 1' is passed to import on use'ing this module, we will
invoke namespace::autoclean to clear out non-methods.

this is a dependency of libdbix-class-schema-loader

Dominique
--
http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont -o- http://ddumont.wordpress.com/




-- 
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/201201311618.57175@debian.org

Bug#658131: ITP: lv2proc -- command line effect processor

[Alessio Treglia]

Package: wnpp
Severity: wishlist
Owner: Alessio Treglia 

* Package name: lv2proc
  Version : 0.4.0
  Upstream Author : Stefano D'Angelo 
* URL : http://naspro.atheme.org/applications/lv2proc
* License : GPL
  Programming Lang: C
  Description : command line effect processor

 LV2proc is a simple command line effect processor using LV2
 plugins.
 .
 lv2proc generates an output sound file by applying a LV2 effect
 plugin to an input sound file.




-- 
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/20120131152917.14760.71825.reportbug@alessio-laptop

Re: Bug#605090: Linux 3.2 in wheezy

[micah anderson]

On Mon, 30 Jan 2012 22:26:50 +0100, Yves-Alexis Perez  wrote:
> On lun., 2012-01-30 at 14:08 +, Ben Hutchings wrote:
> > On Mon, 2012-01-30 at 11:05 +0100, Yves-Alexis Perez wrote:
> > > (adding few CC:s to keep track on the bug)
> > > 
> > > On dim., 2012-01-29 at 21:26 +, Ben Hutchings wrote:
> > > > On Sun, 2012-01-29 at 20:57 +0100, Yves-Alexis Perez wrote:
> > > > > On dim., 2012-01-29 at 18:22 +, Ben Hutchings wrote:
[...]
> > > Now, I still think having a hardened Debian kernel inside the
> > > distribution is helpful
> > [...]
> > 
> > I agree and I would like to see hardening of *all* our configurations,
> > where the performance cost is not too much.  That's going to protect all
> > our users rather than just people who seek out a special paranoid
> > configuration.

Would you agree that there are some small hardening things that can be
done that don't impact performance that much? In particular the
privilege boundries mentioned earlier does not seem to introduce any
particular performance cost worth worrying about.

> So I think it's perfectly clear that nor Debian nor Grsecurity are
> really interested in Debian shipping a Grsecurity kernel.

Well, I don't think its fair to say "Debian" is not interested in
shipping a Grsecurity kernel. I think its more accurate to say that the
current configuration of the Debian kernel team doesn't find the time to
deal with it... but I'm not sure that speaks for all of Debian.

> I find that sad, because I do think there are users of both which would
> benefit from that, and not only people who seek out a special paranoid
> configuration.

I agree. On some machines, I would gladly trade perfomance for a
hardened kernel where that is more important and it is unfortunate that
the attempt to appeal to all possible configurations at the same time
results in a kernel that doesn't allow for specialized configurations
that people want/need.

> Anyway, I'll keep updating the current setup for interested people, but
> without any interest from either party, that definitely looks like a
> dead end.

What is stopping you from creating another package, that provides the
kernel with grsecurity patches applied? Don't bother the kernel team
with it, and just maintain it yourself in the archive? Its free software
afterall. 

micah


pgpxXROPKfhj5.pgp
Description: PGP signature

Re: Linux 3.2 in wheezy

[Dominik Schulz]

Am Montag, 30. Januar 2012, 11:44:10 schrieb Marco d'Itri:
> On Jan 30, Holger Levsen  wrote:
> > > http://blog.bofh.it/debian/id_413
> > 
> > would you mind filing a bug about this?! Refering to your blog post is
> > nice,
> 
> Yes, since the upstream maintainers do not consider this to be a bug.

What are they writing this software for then?

The very same issues you've mentioned give me headaches, too.

I'm very sad to loose vserver support with wheezy.

I know I could compile my own kernel, but I try to avoid this whenever 
possible.
-- 
Mit freundlichen Grüßen / Best Regards
Dominik

vboxadm.net - Postfix admin Interface


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

mass bug filing of 'ucf: command not found' errors detected by piuparts

[Andreas Beckmann]

Hi,

I'm planning to file bugs against all packages that currently fail the
piuparts test with a 'ucf: command not found' error in wheezy and sid.
Currently 22 binary packages from 16 source packages are affected.

Most of these errors happen during the 'postrm purge' phase because
non-essential programs are called by the maintainer script without
checking their existance.

The 'command-not-found' failure logs are available from
http://piuparts.debian.org/sid/command_not_found_error.html
http://piuparts.debian.org/wheezy/command_not_found_error.html

The 'postinst-failed' logs (mostly due to command-not-found, so showing
more or less the same packages) are here:
http://piuparts.debian.org/sid/unknown_purge_error.html
http://piuparts.debian.org/wheezy/unknown_purge_error.html

I'll file these bugs with Severity: important since having a piuparts
clean archive is a release goal since lenny.

The bug report will be based on this template:


Hi,

during a test with piuparts I noticed your package failed to purge
due to a command not found. According to policy 7.2 you cannot rely
on the depends being available during purge, only the essential
packages are available for sure.

Please see the manpages ucf(1), ucfr(1) and the example maintainer
scripts under /usr/share/doc/ucf/examples/ for correct usage of ucf.

Filing this as important because a.) it's a clear policy violation
(to not clean up at purge) b.) having a piuparts clean archive is a
release goal since lenny and c.) this package being piuparts buggy
blocks packages depending on it from being tested by piuparts (and
thus possibly the detection of more severe problems).

From the attached log (scroll to the bottom...):

$LOGEXCERPT

Attachment: $PACKAGE_$VERSION.log.gz


The logfiles will be checked individually to determine that the
command-not-found is really the most serious error and caused the test
to fail.

Following is a list of maintainers and their source packages that have
at least one binary package that both fails the piuparts test and has
'ucf: not found' errors (but may contain false positives).


Regards,

Andreas


Alexander Wirt 
   icinga (U)

Benoit Mortier 
   fusioninventory-agent (U)

Bradley Bell 
   rt-extension-assettracker (U)

Cameron Dale 
   torrentflux

Christoph Haas 
   cream
   cream (U)
   zabbix

Dan Poltawski 
   moodle (U)

Debian Nagios Maintainer Group 
   icinga
   ndoutils (U)

Debian QA Group 
   webissues-server

Debian Request Tracker Group

   rt-extension-assettracker
   rtfm

Dominic Hargreaves 
   movabletype-opensource
   rt-extension-assettracker (U)
   rtfm (U)

Fabio Tranchitella 
   zabbix (U)

Gonéri Le Bouder 
   fusioninventory-agent

Hendrik Frenzel 
   ndoutils

Jan Christoph Nordholz 
   autofs5

Jan Wagner 
   icinga (U)

Jeroen Schot 
   cream

Michael Ablassmeier 
   zabbix (U)

Moodle Packaging Team 
   moodle

Neil Roeth 
   psgml

Niko Tyni 
   rtfm (U)

Patrick Matthäi 
   webissues-server

Penny Leach 
   moodle (U)

Pierre Chifflier 
   ocsinventory-agent

Radu Spineanu 
   simba

Reinhard Tartler 
   boxbackup

Tomasz Muras 
   moodle (U)

Xavier Oswald 
   moodle (U)


-- 
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/4f28218d.8020...@abeckmann.de

Re: Bulding cross-toolchains in the archive

[Wookey]

+++ DrEagle [2012-01-25 14:58 +0100]:
> Hi all,
> 
> I have not so time available too, but :
> - I need a good cross toolchain solution for armel/armhf.
> - I use debian on my sheevas and desktops
> - I have allready made a port of DoudouLinux Debian based system on
> Genesi SmartBook
> - I have a lot of others projects still in progress or in standby...
> 
> Le 23/01/2012 16:28, Wookey a écrit :
> > However right now no-one is really working on this much. Hector is
> > busy with armhf stuff (and a new job). I'm working on sbuild/buildd
> > multiarch cross-building. 
> > 
> > If anyone wants to take the glory by actually making this work (it
> > probably isn't very hard at this stage) you are very welcome. The
> > debian-embedded list is the place where this stuff gets discussed.
> 
> I can be interested by taking the glory by making things works.
> - What are the needed stuff ?
> - How can I start study what had been already done ?
> - What's next to be acomplish ?
> - Who can help in taking needed informations, best practice, and stuff
> that I may forget ?

Sorry I've failed to reply to this offer quickly, for which I apologies. 
I've been a tad busy. 

What I suggest you do is download 'buildcross' from experimental and
try building current gcc versions and see how much breakage there is.
If you are really lucky it all just works :-)

http://packages.debian.org/experimental/buildcross
with current svn here: 
http://www.emdebian.org/repos/current/emdebian/trunk/buildcross/trunk/

Top-level info is here: http://wiki.debian.org/EmdebianToolchain
with buildcross info here:
http://wiki.debian.org/EmdebianToolchain#Emdebian.org_toolchain_autobuilder_.28deprecated.29

All that buildcross does is try to automate the process of downloading
sources, configuring and building and generating and installing
cross-tools as described on this page:
http://wiki.debian.org/BuildingCrossCompilers
and it lets you loop over multiple architectures and toolchain
versions. 

Going through that will give you an understanding of the build process.

Hector has done most of the work on this recently and can no doubt
tell you what was broken last time he looked at it.

What we need to accomplish is having a package to upload which will
build cross-toolchains. The significant change from buildcross is that
instead of using dpkg-cross to generate a libc6-dev-armel-cross package,
it should just build-depend on libc6-dev:armel
similarly for linux-libc-headers-dev:armel

This could be done as one package which builds binutils- and
gcc-. In that case you could use the ubuntu package
armel-cross-toolchain-base- as inspiration, but that can be
significantly simplified as there is no need to do the 3-stage
bootstrap, or build eglibc or linux-headers. 

Or it could be done as a package that builds binutils-, and
another that builds gcc- package is generated whch pulls in the right
things, and something to install the pkg-cfg- link, but these
are minor items. 

You can get help on the debian-embedded mailing list.

I hope that all makes sense and hasn't hopelessly daunted you :-)

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20120131182852.gb6...@dream.aleph1.co.uk

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Michael Biebl]

On 31.01.2012 18:14, Andreas Beckmann wrote:
> Hi,
> 
> I'm planning to file bugs against all packages that currently fail the
> piuparts test with a 'ucf: command not found' error in wheezy and sid.
> Currently 22 binary packages from 16 source packages are affected.
> 
> Most of these errors happen during the 'postrm purge' phase because
> non-essential programs are called by the maintainer script without
> checking their existance.
> 

Interesting timing. initscripts started depending on ucf just a few days
ago, which makes ucf quasi-essential.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Luk Claes]

On 01/31/2012 08:01 PM, Michael Biebl wrote:
> On 31.01.2012 18:14, Andreas Beckmann wrote:
>> Hi,
>> 
>> I'm planning to file bugs against all packages that currently
>> fail the piuparts test with a 'ucf: command not found' error in
>> wheezy and sid. Currently 22 binary packages from 16 source
>> packages are affected.
>> 
>> Most of these errors happen during the 'postrm purge' phase
>> because non-essential programs are called by the maintainer
>> script without checking their existance.
>> 
> 
> Interesting timing. initscripts started depending on ucf just a few
> days ago, which makes ucf quasi-essential.

Unless you are going to argue to add it to the essential set, I can't
see why that matters. It's still wrong to use non-essential packages
in postrm unconditionally. One could even argue that an essential
package should not use ucf unconditionally and have a sane fall back
when it's not available.

Cheers

Luk


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

Re: Proposed mass bug-filing/NMUing: perl 4 libraries

[Julien Valroff]

Hi,

Le lundi 30 janv. 2012 à 20:18:25 (+0100 CET), Dominic Hargreaves a écrit :
> I would like to try and ensure that wheezy releases without any packages
> which use the deprecated perl 4 libraries without depending on the
> separate libperl4-corelibs-perl package.

[...]

> Debian DSPAM Maintainers 
>dspam

This is already fixed upstream, ctime.pl was replaced by POSIX::ctime - this
change will be part of the next release, and can easily be backported if
needed.

Cheers,
Julien

-- 
  .''`.   Julien Valroff ~  ~ 
 : :'  :  Debian Developer & Free software contributor
 `. `'`   http://www.kirya.net/
   `- 4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1


-- 
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/20120131192107.gc6...@kirya.net

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Steve Langasek]

On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote:
> > Interesting timing. initscripts started depending on ucf just a few
> > days ago, which makes ucf quasi-essential.

> Unless you are going to argue to add it to the essential set, I can't
> see why that matters. It's still wrong to use non-essential packages
> in postrm unconditionally. One could even argue that an essential
> package should not use ucf unconditionally and have a sane fall back
> when it's not available.

Well, I would argue that packages in the essential set shouldn't be adding
new dependencies without some discussion and review on debian-devel first. 
That's not technically required by policy, but pulling new packages into the
transitively-essential package set has the same sort of potentially
disruptive effect on upgrades that adding pre-depends does.

But the only reason I see for a transitively-essential package to avoid
using ucf unconditionally is if it *doesn't* have a dependency on it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

lack of replacement for linux-vserver

[Andrei Morgan]

Hi,

I have been aware for a few years that linux-vserver was planned to be
dropped from the next stable release in favour of 'lxc' as a
replacement solution. 

As I believe has been recently discussed on this list, lxc is far from
ready for production use, and there is no other good replacement that I
am aware of.

I therefore would like to add my voice to those asking that vservers are
*not* dropped at the present time, and that this should instead be
reconsidered for a future release, after wheezy.

Of course, if I have missed any blindingly obvious container-type
alternative, please do let me know! Additionally, as I am not subscribed
to this list, please cc me in any response.

Best wishes, and thanks for all the hard work!

 -- Andrei



signature.asc
Description: Digital signature

Re: alioth is down (again)

[Wouter Verhelst]

On Tue, Jan 31, 2012 at 09:31:00AM +0800, Paul Wise wrote:
> On Tue, Jan 31, 2012 at 2:58 AM, Julien Cristau wrote:
> 
> > Like ldapsearch(1)?  That kind of already exists...
> 
> More like a frontend to ldapsearch that doesn't require people to know
> about LDAP, about the Debian schema, nor ldapsearch itself.

Yes, but that doesn't require a machine-parsable version of
machines.cgi, does it?

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120131200325.gb20...@grep.be

Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Andreas Tille]

Hi,

this problem concerns missing *.mime file which breaks other programs
like for instance see

$ see test.pdf 
Error: no "view" mailcap rules found for type "application/pdf"


On Tue, Jan 31, 2012 at 07:57:39PM +0100, Michael Biebl wrote:
> severity 658139 wishlist
> tags 658139 + wontfix

:-(
This is definitely not "wishlist" - but I do not like to play
severity-changing pingpong.

> On 31.01.2012 17:18, Andreas Tille wrote:
> > Package: evince
> > Severity: important
> > Tags: patch
> > 
> > Hi,
> > 
> > several programs (for instance see, mc) are regarding mime entries
> > in mailcap file and can not find a PDF viewer in case only evince is
> > installed.  This ends up in something like:
> 
> Since Joss has removed this file on purpose, it's very unlikely that it
> is coming back.
> 
> This topic has been discussed several times already. Instead of
> maintaining these files by hand (remember, we do have quite a few in the
> GNOME repo), those mailcap entries should be generated automatically
> from the *.desktop files that are provided upstream and already contain
> all the necessary information.
> We don't want to maintain a second mime database by hand in parallel.

So the existence of a potential but not implemented solution rectifies
to break other packages?  That's  ...  uhmm, my vocabulary is broken. :-(
 
> From our pov, someone interested in this topic should write a small
> tool, which does this automatically and is dpkg triggered.

I agree that an automatic solution would be prefered.  However, as long
as such someone does not stand up and write such a program removing
existing solutions is .  I
rarely have read this kind of argument on a Debian mailing list.

Kind regards

Andreas.

-- 
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
Archive: http://lists.debian.org/20120131205154.gc7...@an3as.eu

Re: Breaking programs because a not yet implemented solution exists in theory (Was: Bug#658139: evince: missing mime entry)

[Cyril Brulebois]

Andreas Tille  (31/01/2012):
> This is definitely not "wishlist" - but I do not like to play
> severity-changing pingpong.

Please avoid “To: debian-devel@” when you disagree with maintainers on
individual bugs; thanks already.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Breaking programs because a not yet implemented solution exists in theory

[Russ Allbery]

Cyril Brulebois  writes:
> Andreas Tille  (31/01/2012):

>> This is definitely not "wishlist" - but I do not like to play
>> severity-changing pingpong.

> Please avoid “To: debian-devel@” when you disagree with maintainers on
> individual bugs; thanks already.

Er, peer review seems like a primary purpose of the mailing list to me.

-- 
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/8739avy2wa@windlord.stanford.edu

Re: lack of replacement for linux-vserver

[Ben Hutchings]

On Tue, Jan 31, 2012 at 07:48:02PM +, Andrei Morgan wrote:
> 
> Hi,
> 
> I have been aware for a few years that linux-vserver was planned to be
> dropped from the next stable release in favour of 'lxc' as a
> replacement solution. 
> 
> As I believe has been recently discussed on this list, lxc is far from
> ready for production use, and there is no other good replacement that I
> am aware of.
>
> I therefore would like to add my voice to those asking that vservers are
> *not* dropped at the present time, and that this should instead be
> reconsidered for a future release, after wheezy.
[...]

Debian is a do-ocracy and no-one has been prepared to do that work.

Just to be clear, 'that work' is not just a matter of forwarding
messages back and forward between the Debian BTS and the Linux-VServer
developers.  Unless the VServer project continues to support whichever
version we use in a stable release (3.2 in this case) then Debian
users are likely to run into different bugs that they won't want to
deal with.  There will also be integration issues to be resolved when
fixes from the stable/longterm branch conflict with the VServer
changes.  This requires real understanding of Linux and VServer
internals (see #618485 for an example of what happens without that).

If anyone wishes to volunteer to maintain VServer in Debian - you are
very welcome, but please start by addressing the bugs filed against
them in squeeze and reviewing the existing conflicts.  If you can
prove yourself by doing that, then you may convince me and the rest of
the kernel team that you can maintain it in wheezy as well.
Otherwise, no chance.

The above all applies to OpenVZ as well, and what I've suggested to is
that the interested developers maintain an APT repository of kernel
packages for Debian using whichever version the OpenVZ project is
prepared to support.  Maybe the Linux-VServer project can do that too.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Holger Levsen]

Hi,

On Dienstag, 31. Januar 2012, Michael Biebl wrote:
> Interesting timing. initscripts started depending on ucf just a few days
> ago, which makes ucf quasi-essential.

where was this discussed/announced?


cheers,
Holger


-- 
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/201201312303.40162.hol...@layer-acht.org

Re: mass bug filing of 'ucf: command not found' errors detected by piuparts

[Roger Leigh]

On Tue, Jan 31, 2012 at 11:52:42AM -0800, Steve Langasek wrote:
> On Tue, Jan 31, 2012 at 08:10:11PM +0100, Luk Claes wrote:
> > > Interesting timing. initscripts started depending on ucf just a few
> > > days ago, which makes ucf quasi-essential.
> 
> > Unless you are going to argue to add it to the essential set, I can't
> > see why that matters. It's still wrong to use non-essential packages
> > in postrm unconditionally. One could even argue that an essential
> > package should not use ucf unconditionally and have a sane fall back
> > when it's not available.
> 
> Well, I would argue that packages in the essential set shouldn't be adding
> new dependencies without some discussion and review on debian-devel first.

Hopefully we can remove the ucf dependency; please see #648433.
Currently /etc/default/rcS is intentionally only installed once
during a fresh install, and never updated afterward.  However,
this precludes ever updating it.  Ideally we could make it a
conffile and handle it entirely with dpkg; this would probably
require splitting out the variables which should never be touched
into a separate file under /etc/defaults.


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
Archive: http://lists.debian.org/20120131220722.gz8...@codelibre.net

Re: Linux 3.2 in wheezy

[Christoph Anton Mitterer]

On Mon, 2012-01-30 at 08:02 -0500, Brad Spengler wrote:
> Frankly it makes more sense for me to offer .debs myself than to deal 
> with a bureaucracy and non-standard kernel in Debian.  It contains 
> who-knows-what extra code, and I doubt anyone looked at any of it to see if 
> it allows for some way to leak information I prevent against a vanilla 
> kernel, or a way to bypass any other existing protection.  There's more 
> to security (a whole-system concept) than just the ripping of individual 
> features.

Well I guess it's always more difficult to integrate with something
(upstream or as here the rules from Debian)... but I guess this way one
would have the best chances that many users can/will use it and,
moreover, that it could become the default some day.

When (Debian) users have to take patches or packages from a 3rd party
site ("yours")... they'll typically face more problems,... not only
patching/compiling on their own, but they also lack the support of the
community.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug#605090: Linux 3.2 in wheezy

[Thomas Goirand]

On 02/01/2012 12:01 AM, micah anderson wrote:
> What is stopping you from creating another package, that provides the
> kernel with grsecurity patches applied? Don't bother the kernel team
> with it, and just maintain it yourself in the archive? Its free software
> afterall. 
>
> micah
>   
Having such option to choose between a normal (as default),
and grsec kernel (if you know what you're doing (tm)), would
really be great, IMO. Yves-Alexis, don't just discard it!

Thomas


-- 
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/4f287f13.2070...@goirand.fr

Re: Proposed mass bug-filing/NMUing: perl 4 libraries

[Steve McIntyre]

Dom wrote:
>I would like to try and ensure that wheezy releases without any packages
>which use the deprecated perl 4 libraries without depending on the
>separate libperl4-corelibs-perl package.
>
>You can see more details, and a list of packages, at
>
>and
>
>
>I would like to file bugs against these packages, together with patches
>if possible, to fix the issues (I'm hoping that other members of the
>Debian Perl group might be able to help out with this, too).
>Severity: normal seems appropriate, at least initially.

...

>Steve McIntyre <93...@debian.org>
>   nas

Fixed package in incoming now.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"You can't barbecue lettuce!" -- Ellie Crane


-- 
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/e1rspgr-00045k...@mail.einval.com

Re: lack of replacement for linux-vserver

[Paul Wise]

On Wed, Feb 1, 2012 at 5:37 AM, Ben Hutchings wrote:

> Just to be clear, 'that work' is not just a matter of forwarding
> messages back and forward between the Debian BTS and the Linux-VServer
> developers.  Unless the VServer project continues to support whichever
> version we use in a stable release (3.2 in this case) then Debian
> users are likely to run into different bugs that they won't want to
> deal with.  There will also be integration issues to be resolved when
> fixes from the stable/longterm branch conflict with the VServer
> changes.  This requires real understanding of Linux and VServer
> internals (see #618485 for an example of what happens without that).

Data point; there is a VServer patch for 3.2 (marked as experimental though):

http://vserver.13thfloor.at/Experimental/patch-3.2.2-vs2.3.2.6.diff

It was also claimed on IRC that when using the Debian template for lxc
(see below) that the security issues mentioned in the Linux 3.2 thread
do not apply.

lxc-create -t debian
/usr/lib/lxc/templates/lxc-debian

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Bug#658213: ITP: django-fixture-generator -- reusable django application to make writing fixtures not suck

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: django-fixture-generator
  Version : 0.2.0
  Upstream Author : Alex Gaynor 
* URL : http://pypi.python.org/pypi/django-fixture-generator
* License : BSD
  Programming Lang: Python
  Description : reusable django application to make writing fixtures not 
suck

 By adding `fixture_generator'' to the `INSTALLED_APPS'' setting,
 creating a `fixture_gen.py'' file (see the included documentation for an
 example) in one of the apps, it is possible to quickly and easily
 generate fixtures.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCAAGBQJPKKj9AAoJECzXeF7dp7IPwsIQAKmc1b0tGtX3HjH50n4YbsGX
K/BZrjUSAg6cHkDknBhjD/WiiwqjU3hIIRWMPLRHyPOTNYtQyA/i6BqzDJoHs+Ow
fPuDmbxwxLXfPqU5Lv6Htd7YgdjdUQ883VraKgBaao8VwQN/TP5/g46xKbHliyRL
GsOmrnJQj3yik6DlA4MHg1H3vSzxOKvqTwa3Nz6l7KkLCQLQ00+j1FTwN+EeAe+0
OilOcfC4BydizWo1FKQdE57HZC5O14QoTfZhfd3AhYeKX9Ehip8htPkTlku3R6Yq
2gMaMAqEI/S1RlSZ2IWeNRmKqQc7kFyeSe9q1zyVX+Co3fiDjJVBytUsiqEmtl36
ToujTKIsXos/Yf7bdeUfFTCfn84z+3N+AcVncTNCuvA0Mjficrq/EOKKe015IyEx
dh0UXOW8o3naoJH2hJVi5ysflwYlYyvS/wSxRvPub5eq/ad4tERxbc6ShAiFzN2J
yJKrwFlX26WCf57/Y8lRT9e5CYzJ8y5bjKHXEun0ByGNXedwxwiwrBvf/KhpmF/n
NMHCdb4YKHqoQQ7Pz4Fg9E9bqfZU6vw4fv2fs+RvUcXafjbSohvPdJq6jdjlGJRY
/afIDnYMCIgesG43ahyhwy/pryS3WD6VI4D+QJDksN8yIVmkYnsX/1jwi6TNulZO
c4m07Z+y2R+CiRu0HCF+
=IbBD
-END PGP SIGNATURE-



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