ITP: mm3d -- Misfit Model 3D

[Gürkan Sengün]

Package: wnpp
Severity: wishlist

* Package name: mm3d
  Version : 1.2.4 or/and 1.3.4
  Upstream Authors: Kevin Worcester <[EMAIL PROTECTED]>
* URL : http://www.misfitcode.com/misfitmodel3d/
* License : GNU GPL
  Description : Misfit Model 3D
 This is an OpenGL-based 3D model editor that works with triangle-based models.
It supports multi-level undo, skeletal animations, simple texturing, scripting, 
command-line batch processing, and a plugin system for adding new model and image 
filters. Complete online help is included. It is designed to be easy to use and 
easy to extend with plugins and scripts.


I might put the 1.3.4 into experimental once 1.2.4 is done.

The reason I do this is because of people (including me) might want to make
models in md3 for www.sauerbraten.org (which is also packaged in debian,
non-free and contrib, because nobody wants to go through the licenses
of the maps and textures, and sounds -- irc.quakenet.org #sauerbraten)
The md3 part needs a plugin I'll do later.

-- System Information:
Debian Release: testing/unstable
Architecture: powerpc
Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc
Locale: LANG=POSIX, LC_CTYPE=POSIX




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

Filing FTBFS bugs and packages in NEW

[Kari Pahula]

I'd like to file a wishlist bug on people who file FTBFS bugs.

It would be nice if you checked first whether there's a package
pending in NEW or incoming and see if that might resolve the issue
already.

I'm looking at you, #426867.

Thank you.


signature.asc
Description: Digital signature

Re: Bug#426874: ITP: pkg -- High-level library for managing Debian package information

[Enrico Zini]

On Fri, Jun 01, 2007 at 11:41:45AM +0200, Stefano Zacchiroli wrote:

> Great to see this!, but I'm rather scared about its name: isn't "pkg"
> too generic? Wouldn't "debpkg" be a better (since more specific and
> describing) name?

After some discussion in #debian-devel, I went for 'upt'.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Filing FTBFS bugs and packages in NEW

[Ron Johnson]

On 06/01/07 04:59, Kari Pahula wrote:

I'd like to file a wishlist bug on people who file FTBFS bugs.

It would be nice if you checked first whether there's a package
pending in NEW or incoming and see if that might resolve the issue
already.

I'm looking at you, #426867.


Even though "I" am not #426867, how do you access the NEW queue?

--
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!


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

Re: Bug#426874: ITP: pkg -- High-level library for managing Debian package information

[Ron Johnson]

On 06/01/07 04:41, Stefano Zacchiroli wrote:

On Thu, May 31, 2007 at 01:29:47PM +0100, Enrico Zini wrote:

* Package name: pkg
  Description : High-level library for managing Debian package information


Great to see this!, but I'm rather scared about its name: isn't "pkg"
too generic? Wouldn't "debpkg" be a better (since more specific and
describing) name?


That, too, I think is too generic.

metadebpkg, maybe?

--
Ron Johnson, Jr.
Jefferson LA  USA

Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!


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

Re: Filing FTBFS bugs and packages in NEW

[Frans Pop]

On Friday 01 June 2007 12:35, Ron Johnson wrote:
> Even though "I" am not #426867, how do you access the NEW queue?

Google for "debian new"; third hit:
http://ftp-master.debian.org/new.html

You cannot access the packages themselves, but it does show which bugs are 
fixed.


pgpQ8mG5NQ35A.pgp
Description: PGP signature

Re: Filing FTBFS bugs and packages in NEW

[Adam D. Barratt]

Ron Johnson wrote:

On 06/01/07 04:59, Kari Pahula wrote:

I'd like to file a wishlist bug on people who file FTBFS bugs.

It would be nice if you checked first whether there's a package
pending in NEW or incoming and see if that might resolve the issue
already.

I'm looking at you, #426867.


Even though "I" am not #426867, how do you access the NEW queue?


For appropriate values of "access" - http://ftp-master.debian.org/new.html

Adam


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

Re: ITP: mm3d -- Misfit Model 3D

[Bernd Zeimetz]

>   Description : Misfit Model 3D
>  This is an OpenGL-based 3D model editor that works with triangle-based
> models. [...]

unfortunately the short description doesn't tell anything about the
package, except the name(?). Peopel would have to read the long
description to figure out what the package is at all. What about:

Description:   OpenGL-based 3D model editor
Misfit Model 3D works with triangle-based models. [...]


Cheers,


Bernd
-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


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

Re: Bug#426874: ITP: pkg -- High-level library for managing Debian package information

[Stefano Zacchiroli]

On Thu, May 31, 2007 at 01:29:47PM +0100, Enrico Zini wrote:
> * Package name: pkg
>   Description : High-level library for managing Debian package information

Great to see this!, but I'm rather scared about its name: isn't "pkg"
too generic? Wouldn't "debpkg" be a better (since more specific and
describing) name?

Just my 0.02€,
Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Morten Kjeldgaard]

Hi,

I once wrote a small python utility called udist that tries to work out 
which distribution it runs on. It works on several RPM based 
distributions, as well as the Debian based distros I've tested. I 
originally had in mind putting the project on a public server and 
involving more people to test and implement more distros but I never got 
around to it.


The utility makes use of different strategies when attempting to fill 
out the different fields. It can use LSB but can also carry on with out 
it as in the example below.


This is the kind of output I get on my Ubuntu machine:

[EMAIL PROTECTED] udist]$ bin/udist
No LSB modules are available.
id:ubuntu
name:Ubuntu
codename:feisty
desc:Ubuntu 7.04
rel:7.04
rel_major:7
family:debian
sfam:ubuntu
reltag:ubuntu7
processor:
machine:i686
arch:i386

... and this is from a CentOS machine:

[EMAIL PROTECTED] ~]$ udist
id:centos
name:CentOS
codename:Final
desc:CentOS release 4.4 (Final)
rel:4.4
rel_major:4
family:redhat
sfam:rhel
reltag:el4
processor:athlon
machine:i686
arch:i386

By using switches (a la uname) you can output specific fields. I've put 
a .tar.gz file here:  ftp://ftp.bioxray.dk:/pub/mok/src/udist-0.5.tar.gz 
if you're interested.


I anyone wants to join in and extend/rewrite/improve this utility, let 
me know.


Cheers,
Morten

--
Morten Kjeldgaard, Asc. professor, Ph.D.
Department of Molecular Biology, Aarhus University
Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark
Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178
Home +45 86188180 * http://www.bioxray.dk/~mok


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Morten Kjeldgaard]

PS: To address the original question: Being a molecular biologist, my 
initial idea was to use an approach similar to that used in gene 
analysis: look at the entire set of packages installed on a specific 
system (package name and version), and then determine what known distro 
the set is closest related to.


I put that aside because I wanted something working quickly, but the 
idea of being able to make a "family tree" of distros still seems like 
fun. It isn't hard to do.


Cheers,
Morten

--
Morten Kjeldgaard, Asc. professor, Ph.D.
Department of Molecular Biology, Aarhus University
Gustav Wieds Vej 10 C, DK-8000 Aarhus C, Denmark
Lab +45 89425026 * Mobile +45 51860147 * Fax +45 86123178
Home +45 86188180 * http://www.bioxray.dk/~mok


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

Last call for keys for keysigning in Edinburgh during DebConf7

[Aníbal Monsalve Salazar]

Hello All,

As part of the 8th Debian Conference in Edinburgh, Scotland, there
will be OpenPGP (pgp/gpg) keysignings. If you intend to participate
in the DebConf7 keysignings, please send your ascii armored public
key as explained at [0] not later than Saturday 9th of June, 2007
(UTC).

To considerably reduce the time spent checking ID documents, each
participant will be placed in one of a number of groups after all
the keys have been received. The groups will be organized after
computer simulations are run to (heuristically) optimize the mean
shortest distance (MSD) of all participants.

More (and up-to-date) information is available at [0].

If you have sent your key and your name is not listed at [1],
please resend it. If you have problems please send me a mail
message.

[0] https://debconf7.debconf.org/wiki/Keysigning
[1] https://debconf7.debconf.org/~ksp/names.html


===

About DebConf:

DebConf is the Debian Project's developer conference. In addition
to a full schedule of technical, social and policy talks, DebConf
provides an opportunity for developers, contributors and other
interested people to meet in person and work together more closely.
It has taken place annually since 2000 in locations as varied as
Canada, Finland and Mexico.

DebConf is preceded by DebCamp, which is a smaller, less formal
event that gives an opportunity for group work on Debian projects.
Between both events, DebianDay takes place. DebianDay is a short
conference aimed at Debian users, and others interested in learning
more about free software.

About Debian:

The Debian Project is an association of Free Software developers
who volunteer their time and effort in order to produce the free
operating system Debian GNU/Linux.

About Edinburgh:

Edinburgh, voted best UK city for seven years running (Guardian
Travel Awards), is the capital of Scotland. DebConf7 will take
place in central Edinburgh, within the UNESCO World Heritage site.


Anibal Monsalve Salazar
-- 
http://v7w.com/anibal


signature.asc
Description: Digital signature

Bug#427029: ITP: whichwayisup -- 2D platform game with a slight rotational twist

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: whichwayisup
  Version : 0.7.0
  Upstream Author : Olli "Hectigo" Etuaho <[EMAIL PROTECTED]>
* URL : http://hectigo.net/puskutraktori/whichwayisup/
* License : GPL 2.0, Creative Commons 3.0 Attribution license
  Programming Lang: Python
  Description : 2D platform game with a slight rotational twist

Which Way Is Up, a traditional and challenging 2D platform game with a
slight rotational twist. Help a mysterious big-eared salaryman named
Guy find his keys in a labyrinth of dangers and bad dialogue.


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

Re: Filing FTBFS bugs and packages in NEW

[Lucas Nussbaum]

On 01/06/07 at 12:59 +0300, Kari Pahula wrote:
> I'd like to file a wishlist bug on people who file FTBFS bugs.
> 
> It would be nice if you checked first whether there's a package
> pending in NEW or incoming and see if that might resolve the issue
> already.
> 
> I'm looking at you, #426867.

Even if I agree that this would be nice, that's unlikely to happen. When
filing FTBFS bugs, one has to check several things:
(A) Is the bug already reported ?
(B) Has the package changed since the rebuild happened ?
(C) Has the package's dependancies changed since the rebuild happened ?
(D) Recursively, has the package's dependancies' dependancies changed ?

The problem is that it already takes time to file those bugs, and that
there are a lots of bugs to file. For example, on May 22nd, 515 packages
failed to build, and 240 failures have not been analyzed yet, so that's
240 potential RC bugs (of course, some of them might have been reported
already by people not using collab-qa for coordination).

What would be better ? File less higher quality bugs ? I think that the
average level of quality for FTBFS bugs is currently quite good...

In your case, the best solution could have been to document the issue by
filing a bug yourself on your package, so everyone can easily learn
about the problem. It would also have saved the bug reporter some time
as well ;)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: ITP: mm3d -- Misfit Model 3D

[Gürkan Sengün]

description to figure out what the package is at all. What about:

Description:   OpenGL-based 3D model editor
Misfit Model 3D works with triangle-based models. [...]


Fantastic, I've changed that for the 1.2.4 version, and
added the supported file formats [1] to the 1.3.4 (experimental) one:

http://gnu.ethz.ch/debian/misfitmodel3d/

[1] It supports the following 3d files: MilkShape (ms3d), Wavefront (obj),
 LightWave 3d Object (lwo), Quake 2 model (md2), Quake 3 mode (md3),
 Caligari trueSpace (cob), and AutoCAD (dxf).

Cheers,
Gürkan


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

Re: Filing FTBFS bugs and packages in NEW

[Martin Zobel-Helas]

Hi, 

On Fri Jun 01, 2007 at 12:59:14 +0300, Kari Pahula wrote:
> I'd like to file a wishlist bug on people who file FTBFS bugs.
> 
> It would be nice if you checked first whether there's a package
> pending in NEW or incoming and see if that might resolve the issue
> already.

This could be realized by patching helena[1], eg. to produce a RSS like
output, so an automated parsing of PackageName and PackageVersion in NEW
could be done. I will have a look into that during the weekend. Should
be mostly trivial.

Greetings
Martin


[1] helena (or better, her successor) produces
http://ftp-master.debian.org/new.html
-- 
[EMAIL PROTECTED] /root]# man real-life
No manual entry for real-life


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Javier Fernández-Sanguino Peña]

On Fri, Jun 01, 2007 at 12:55:57AM +0200, Santiago Vila wrote:
> I wonder why do we need a file to tell the user about the contents of
> his /etc/apt/sources.list file. Have you read "How do I know which
> distribution I'm running?" in base-files FAQ? The answer is still
> valid for *any* file which is part of an installed package.

We are not telling the user, we are telling *programs* what environment they
are in. Reading /etc/apt/sources.list is useless. Let me give you some use
cases:

- a sysadmin running 'woody', upgraded to 'sarge' by changing his
  /etc/apt/sources.list to point to 'stable'. But has not upgraded the system
  after etch was released
/etc/debian_version   -> CORRECT   info
/etc/apt/sources.list -> INCORRECT info

- a sysadmin running 'sarge' modifies his /etc/apt/sources.list to point to
  'etch', but never upgrades the system. 
/etc/debian_version   -> CORRECT   info
/etc/apt/sources.list -> INCORRECT info

- a sysadmin installed 'etch' using d-i, and upgraded it after December 11th 
  but has not upgraded it before April 10th.
/etc/debian_version   -> INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list -> CORRECT info
  
- a sysadmin installs 'lenny' using d-i, April 9th. But never upgraded
  before that.
/etc/debian_version   -> INCORRECT info (4.0 when it is testing)
/etc/apt/sources.list -> CORRECT info ('testing')
  
Sources.list does not indicate the release the system is running but,
actually, the release the system would be running *if* it was up-to-date and
upgraded.

Moreso, it's completely useless for (some) systems that have been installed from
CD-ROM and do not point to the security mirrors.

It is useful *in*addition* to /etc/debian_version to make a guess and try to
tell apart testing vs. unstable. 

> I really don't understand what you guys want to achieve that might be both
> necessary and really useful (as opposed to just "being a nice thing").

We are trying to simplify the problem some applications might have (not
necessarily those shipped in Debian proper, maybe even for applications that
are for other vendors) in order to determine which system they are in and
take proper action. The problem that was originally stated at the start of
the thread.

The best approach we can provide ('use lsb_release') is prone to errors if
used in the timeframe of a release and, even for some other situations.

In any case, you said [1] there was some (programmatic) way to determine
which Debian release (or even 'non-release') an application is running one
which does not depend on /etc/debian_release. I would be happy to know which
one that is (so that it can be implemented in lsb_release).

Regards

Javier

[1] Message-ID: <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Javier Fernández-Sanguino Peña]

On Fri, Jun 01, 2007 at 02:26:34PM +0200, Morten Kjeldgaard wrote:
> PS: To address the original question: Being a molecular biologist, my 
> initial idea was to use an approach similar to that used in gene 
> analysis: look at the entire set of packages installed on a specific 
> system (package name and version), and then determine what known distro 
> the set is closest related to.

You can check only a subset of packages (most popular ones, for example or
core packages)  and compare with data you extracted the data beforehand or
somebody provides.  For example, see the package data sets at
http://distrowatch.com/debian (these can be easily generated with the
Packages files from the different releases, but you have to have access to
mirrors with old releases too)

Regards

Javier


signature.asc
Description: Digital signature

Re: python, then C++, or C++ from the start?

[Andreas Rottmann]

martin f krafft <[EMAIL PROTECTED]> writes:

> Dear colleagues,
>
> I am starting to write netconf [0], finally. Or rather, I would if
> I could settle on a language. If netconf is ever going to replace
> ifupdown, it would need to have a low footprint and few
> dependencies. This clearly suggests C/C++ as the language of choice.
>
> 0. http://netconf.alioth.debian.org
>
> However, C/C++ make extreme programming rather difficult as it's
> hard to make large-scale changes due to the strict typing and stuff
> like lack of garbage collection or seamless exception handling. I am
> not here to bash C/C++, but you might agree that high-level
> languages such as Python are much better suited for mockup
> implementations, when the overall structure and logic of a programme
> is not yet set in stone.
>
> Since I want netconf released early and often, and I'll be reusing
> a lot of shell script logic at first, throwing stuff around until
> the logical structure and type definitions are adequate, I am
> considering starting first in Python and later, when it's All
> Done(tm), port the application to C++.
>
> I am a well-versed C++ coder and I know which things are possible in
> Python but not in C++, so if I avoid those, this seems like
> a possible approach.
>
> But I am asking you still: can you think of anything to say against
> such an approach? Please don't flame languages or anything of that
> sort. The question is just: is it viable for a C++ coder with
> a Python proficiency to mockup a new application in Python first?
>
I think that approach makes sense.

This isn't what you asked for, but you might be interested in Vala[0],
which compiles to C and has high-level features such as lambda
expressions.

[0] http://live.gnome.org/Vala

Cheers, Rotty
-- 
Andreas Rottmann | [EMAIL PROTECTED]  | [EMAIL PROTECTED] | [EMAIL 
PROTECTED]
http://rotty.uttx.net| GnuPG Key: http://rotty.uttx.net/gpg.asc
Fingerprint  | C38A 39C5 16D7 B69F 33A3  6993 22C8 27F7 35A9 92E7
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

Always be wary of the Software Engineer who carries a screwdriver.
  -- Robert Paul


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

Plugin API/ABI versions

[Magnus Holmgren]

Many applications allow their functionality to be extended by means of 
plugins, often in the form of libraries that the application dlopen()s. 
Usually the application provides an API, and like other APIs these APIs (and 
ABIs) can evolve, calling for versioned dependencies. But executables aren't 
shared libraries, so there are no SONAME/NEEDED tags (typically, AFAIK, the 
API headers define some version constants that the application queries the 
plugin for to detect incompatibilities) and using dpkg-shlibdeps doesn't 
work. So how should the -dev package provide correct dependency information 
in these cases?

- Should the application put necessary parts in a shared library, which 
plugins can link against, thereby making full use of symbol versions 
possible?

- Can the plugins usually simply declare the API version it's actually using 
(which it should know), overriding the version constants in the headers? More 
generally, what can cause a binary, compiled with (say) version 1.1 of 
libfoo.h instead of previously version 1.0 (i.e. it doesn't use any new parts 
of the API) to fail to work with version 1.0 of the library? Changed macros 
that cause a different symbol to be referenced comes to mind. What else, if 
symbols aren't versioned?

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


pgpCQBuAd0W6k.pgp
Description: PGP signature

Re: python, then C++, or C++ from the start?

[martin f krafft]

On 2007-05-31 08:13, Oleg Verych wrote:
> I like shell PITAs. At least it will start to run everywhere by
> `/bin/sh' (dash, busybox, bash, zsh, whatever :)

How do you implement control sockets or listen on the netlink socket
with shell? Do you want to tail 'ip monitor'? Even if, how do you do
control sockets which don't block?

-- 
Please do not send copies of list mail to me; I read the list!
 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"convictions are more dangerous enemies of truth than lies."
 - friedrich nietzsche


signature.asc
Description: Digital signature (GPG/PGP)

libpkg / libupt / libept gets popcon support

[Enrico Zini]

Hello,

the name of the new library is still in flux, and maybe it'll end up
with the name 'libept' and replacing the libept we have now.

But in the meantime, name or no name, I implemented access to popcon
information (!)

It works like this:

 1. Download http://popcon.debian.org/all-popcon-results.txt.gz and put
it either in ~/.popcon/ or in /var/lib/popcon/
 2. When instantiating the Popcon data provider, if it sees that
all-popcon-results.txt.gz is new, it reads it, recomputes the scores
and rebuilds the index.

The index works like the debtags index: it's built in /var/lib/popcon if
it's writable, or in ~/.popcon/ otherwise.

Ideally there should be a 'popcon' commandline tool that does the
download and reindexing, like we now have "debtags update".

The Popcon data provider is now very basic: given a package name, it
gives a float value computed as an aggregated score of the various
popcon values.  The higher the value, the higher is the popularity.

In the next days I intend to implement reading
/var/log/popularity-contest and computing something more interesting,
like TFIDF scores of installed packages.

The aggregated score is computed with this (rather arbitrary) weighted
sum:

  score = vote + recent * 0.5 + old * 0.3 + nofiles * 0.1


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Santiago Vila]

On Fri, 1 Jun 2007, Javier Fernández-Sanguino Peña wrote:

> On Fri, Jun 01, 2007 at 12:55:57AM +0200, Santiago Vila wrote:
> > I wonder why do we need a file to tell the user about the contents of
> > his /etc/apt/sources.list file. Have you read "How do I know which
> > distribution I'm running?" in base-files FAQ? The answer is still
> > valid for *any* file which is part of an installed package.
> 
> We are not telling the user, we are telling *programs* what environment they
> are in.

That's the fundamental mistake I see here: We should not be telling
programs what "release" they are running to begin with. We do not try
to make packages to work under the assumption that they will run
"on a sarge system" or "an etch system". Instead, we try to make them work
as far as their dependencies are met.

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Kris Deugau]

(I keep looking at what I've written, and thinking "That's not quite
right" or "I'm forgetting some critical argument" or "That sounds very
argumentative/rude but I can't think of a better way to phrase it".  I
*have* gotten an interesting discussion out of this thread, however.)

Santiago Vila wrote:
> That's the fundamental mistake I see here: We should not be telling
> programs what "release" they are running to begin with. We do not try
> to make packages to work under the assumption that they will run
> "on a sarge system" or "an etch system". Instead, we try to make them work
> as far as their dependencies are met.

... which means what, exactly, if my program expects
/usr/lib/apache2/suexec but the system (stock Debian sarge) only has
/usr/lib/apache2/suexec2?  Or vice versa for etch?  (Or more accurately,
I need to know in advance - in this case, at package build time - which
name suexec gets so that the Apache config fragment I drop in doesn't
break.)  OK, so if it's one file I can munge in a solution that checks
at install time or something.  What about a case where there are
*hundreds* of little things like this with complicated subcases?

This is the simplest, most prominent example I've run into, but it's far
from the only one.  Most of the rest are somewhat convoluted and
specific to local systems (and a few are related to how I'm building
packages to avoid Debian Policy limitations that conflict with local
policy), but they're very real.

I'm not trying to find something that includes (or resembles)
significant fractions of the hairy mess that is an autotools configure
script (), but a reference I can use to make reasonable assumptions
about what should be on the system if it hasn't been hacked fifteen
different directions with source installs of half the major subsystems
which rely on backports and packages from experimental.

(Mildly amusing sidenote to this discussion:  I'm finally convincing the
senior systems guy that Packages Are Good, and now developers for the
upstream OS seem to be telling me Packages Are Useless, because I can't
even count on a critical dependency being installed via the package
system.  )

-kgd


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

Re: undo configuration file changes

[Steve Greenland]

On 31-May-07, 04:17 (CDT), [EMAIL PROTECTED] wrote: 
> In the Moment i'm packaging some software and wonder if there is a
> possibility to handle files such as crontab or configuration files of
> other programs to add a directive with postinst but also to remove that
> directive with prerm. Is there a predefined possibility for that or do I
> have to implement this in a script?

As Kushal pointed out, packages that expect to interact with other
random packages (e.g. cron with /etc/cron.d) often provide a
subdirectory that they read. Some others provide a program interface to
modify configuration (e.g. update-rc.d).

Other than that, it's usually a bad idea to attempt to modify other
packages' configuration files. If it's a conffile, it's explicitly
forbidden by policy. See policy 10.7 and especially 10.7.4.

Steve 

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Re: python, then C++, or C++ from the start?

[Oleg Verych]

> On 2007-05-31 08:13, Oleg Verych wrote:
>> I like shell PITAs. At least it will start to run everywhere by
>> `/bin/sh' (dash, busybox, bash, zsh, whatever :)
>
> How do you implement control sockets or listen on the netlink socket
> with shell? Do you want to tail 'ip monitor'? Even if, how do you do
> control sockets which don't block?

I'm not one, who wrote http server in bash or Postscript anyway ;)

Seriously. With meaningful wrappers netlink sockets can be handled.
I'm not sure what control sockets are, any why non blocking is a
problem if I/O is line-oriented (mainly).

Moreover, i didn't know `ip' was upgraded to `monitor' functionality!



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

Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Frank Lichtenheld]

On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote:
> (Mildly amusing sidenote to this discussion:  I'm finally convincing the
> senior systems guy that Packages Are Good, and now developers for the
> upstream OS seem to be telling me Packages Are Useless, because I can't
> even count on a critical dependency being installed via the package
> system.  )

? I don't see that beeing said in the thread. Could you point out that
for me?

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: checklib

[Oleg Verych]

* From: Manoj Srivastava
* Date: Wed, 30 May 2007 12:04:01 -0500
* Organization: The Debian Project

[]
>  (I tend not to optimize before determining whether it is needed).

Even trailing whitespace your editor tend not to remove, before X
time ;)

[]
> If someone wants to port my simple shell scripts into gobs
>  and gobs of python; they can get it from ./debian/common/checklibs
>  files in any of my packages; and they can browse on arch.debian.org for
>  easy access.

I've got it from your kernel-package. And want to `release early' my
non working version, mainly due to finding bugs in the binutils's
readelf and comparing it to elfutils'.

Before that, let me publish testcase for surely buggy `readelf':

,---[tst-readelf.sh]
cd /tmp/
exec 2>/dev/null
e=bin.elfs
o=bin.objs

elf() {
readelf -sDW -- $* | sed -n -e '
/LOCAL/d;/UND/{ s_\([^ \t]*\)$_|\1_;s_[^|]*|__;p;}'
}

elf /bin/* | sort -u >$e

objdump -T -- /bin/* | sed -n -e '
/*UND*/{ s_\([^ \t]*\)$_|\1_;s_[^|]*|__;p;}' | sort -u >$o

__diff() {
>$1 diff -u $e $o
ls -l $1
}

__diff elfs_obj.diff # i have non zero diff here and zero one below

echo note size, but [press enter] ; read f

for i in /bin/*
do elf $i
done | sort -u >bin.elfs

__diff 0

echo so, readelf is buggy "?;)"
---'

ftp://flower.upol.cz/checklibs...

here it is anyway.

Notes about original:
- `basename' doesn't work,
- unlink early, rather than that "trap" bloat,
- "progname" isn't used anyway,
- awk, perl overkill, (there could be `python' easyly ;)
- `objdump' can handle one file at time (and not buggy).
+ i would suggest $PATH compatible EXTRA_ syntax

Anyway it works! My is not yet ;)

Reading this thread, i just don't know what to implement (thus how).
If somebody can summarize, i can more forward a bit faster.



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

Re: ADV: Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Kris Deugau]

Frank Lichtenheld wrote:
> On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote:
>> (Mildly amusing sidenote to this discussion:  I'm finally convincing the
>> senior systems guy that Packages Are Good, and now developers for the
>> upstream OS seem to be telling me Packages Are Useless, because I can't
>> even count on a critical dependency being installed via the package
>> system.  )
> 
> ? I don't see that beeing said in the thread. Could you point out that
> for me?

Hmm.  Not explicitly stated, nor really implied, but several people
commented that a system may have backported packages, packages from
testing/unstable/experimental, software that's installed from source and
which the package manager is therefore completely unaware of - in other
words, no matter what you might find in /etc/debian_version or some
other nominal reference, the configuration and binaries on the system
may not resemble a stock install of that release at all.

Taken to the extreme, that leads me to the conclusion that Packages Are
Useless.(Taken another couple of steps, it leads to "Everyone
should be running Linux From Scratch".)

(I don't really think so, and I think the argument about "The local
admin may hack the system up until it resembles Swiss cheese so why
bother doing " has been beaten well beyond death in other threads
I've seen recently.)

Mostly just an impression I got from the trend of some of the responses.

-kgd, wondering how one would go about bootstrapping LFS raw from a
stack of printout and a single modern desktop machine, with no source of
precompiled executables.


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Manoj Srivastava]

On Fri, 01 Jun 2007 14:51:27 -0400, Kris Deugau <[EMAIL PROTECTED]> said: 

> (I keep looking at what I've written, and thinking "That's not quite
> right" or "I'm forgetting some critical argument" or "That sounds very
> argumentative/rude but I can't think of a better way to phrase it".  I
> *have* gotten an interesting discussion out of this thread, however.)

> Santiago Vila wrote:
>> That's the fundamental mistake I see here: We should not be telling
>> programs what "release" they are running to begin with. We do not try
>> to make packages to work under the assumption that they will run "on
>> a sarge system" or "an etch system". Instead, we try to make them
>> work as far as their dependencies are met.

> ... which means what, exactly, if my program expects
> /usr/lib/apache2/suexec but the system (stock Debian sarge) only has
> /usr/lib/apache2/suexec2?

Seems like you should use the new version, and add a versioned
 dependency? 

> Or vice versa for etch?  (Or more accurately, I need to know in
> advance - in this case, at package build time - which name suexec gets
> so that the Apache config fragment I drop in doesn't break.)  OK, so
> if it's one file I can munge in a solution that checks at install time
> or something.  What about a case where there are *hundreds* of little
> things like this with complicated subcases?

Again, the dependency system is your friend. Use it.

manoj

-- 
Having the fewest wants, I am nearest to the gods. Socrates
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: checklib

[Manoj Srivastava]

On Fri, 1 Jun 2007 20:53:10 + (UTC), Oleg Verych
<[EMAIL PROTECTED]> said:  

> Notes about original:
> - `basename' doesn't work,

Why? It seems to work perfectly fine here.
__> basename 
/usr/local/src/arch/packages--debian/kernel-package/kernel-package/debian/common/checklibs
checklibs


> - unlink early, rather than that "trap" bloat,

You do not seem to understand what trap does.  I unlink temp
 files the moment I am done with them.  Traps are set to handle
 exceptions, and to clean up when those occur.

Please read up on signal handling; your remark seems to indicate
 you don't know what it is all about.

> - "progname" isn't used anyway,

Right. It is standard boilerplate for my scripts; I usually use
 it in diagnostic messages; of which none seemed to have survived into
 production. 

> - awk, perl overkill, (there could be `python' easyly ;)

awk and Perl are essential packages; python would mean a
 dependency.  I also don''t like python, so I am unlikely to add python
 code to my build system.

> - `objdump' can handle one file at time (and not buggy).

I don't understand that comment.
,[  Manual page objdump(1) ]
| SYNOPSIS
|objdump [-a|--archive-headers] <>  objfile...
| DESCRIPTION
|objdump  displays  information  about  one  or  more object files. 
`

> + i would suggest $PATH compatible EXTRA_ syntax

I don't understand this comment either.

manoj
-- 
Spelling is a lossed art.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Frank Lichtenheld]

On Fri, Jun 01, 2007 at 04:54:03PM -0400, Kris Deugau wrote:
> Frank Lichtenheld wrote:
> > On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote:
> >> (Mildly amusing sidenote to this discussion:  I'm finally convincing the
> >> senior systems guy that Packages Are Good, and now developers for the
> >> upstream OS seem to be telling me Packages Are Useless, because I can't
> >> even count on a critical dependency being installed via the package
> >> system.  )
> > 
> > ? I don't see that beeing said in the thread. Could you point out that
> > for me?
> 
> Hmm.  Not explicitly stated, nor really implied, but several people
> commented that a system may have backported packages, packages from
> testing/unstable/experimental, software that's installed from source and
> which the package manager is therefore completely unaware of - in other
> words, no matter what you might find in /etc/debian_version or some
> other nominal reference, the configuration and binaries on the system
> may not resemble a stock install of that release at all.

But all of these problems except for the "software not installed as a
package at all" are actually solvable inside the packages system. It is
not solvable by polling a simple one-line file because the system is
too complex for that, but the vastly larger /var/lib/dpkg/status has
all the information you need.

So your reason for stating (admittely half-joking, but still) that
packages are useless is because they can't help you if you don't use
them? That's too lame to be funny, IMHO...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Re: Is there a way to positively, uniquely identify which Debian release a program is running on?

[Steve Langasek]

On Fri, Jun 01, 2007 at 02:51:27PM -0400, Kris Deugau wrote:
> Santiago Vila wrote:
> > That's the fundamental mistake I see here: We should not be telling
> > programs what "release" they are running to begin with. We do not try
> > to make packages to work under the assumption that they will run
> > "on a sarge system" or "an etch system". Instead, we try to make them work
> > as far as their dependencies are met.

> ... which means what, exactly, if my program expects
> /usr/lib/apache2/suexec but the system (stock Debian sarge) only has
> /usr/lib/apache2/suexec2?  Or vice versa for etch?  (Or more accurately,
> I need to know in advance - in this case, at package build time - which
> name suexec gets so that the Apache config fragment I drop in doesn't
> break.)

And what do you do when the system says it's "sarge", but the user trying to
install your package is using a backport of apache2.2 because they needed
some new feature, so suexec is under the new name?

What do you do when the user installs the "sarge" version of your package,
and then does a partial upgrade to etch?  Heck, what do you do when the user
installs the "sarge" version of your package, and does a *full* upgrade to
etch?  There's no channel by which your package is going to be notified of
the changes to the versions of other installed packages.

Package dependencies are the right answer here, not distribution-based
guessing.

> OK, so if it's one file I can munge in a solution that checks
> at install time or something.  What about a case where there are
> *hundreds* of little things like this with complicated subcases?

Then you have a difficult task ahead of you to create a package that works
for your users.  But it's quite unrealistic that you will ever have a case
of hundreds of little, *independent* things that differ between dists that
you need to check for.  Your hundred little changes are probably reducible
to three or four versioned dependencies.

> (Mildly amusing sidenote to this discussion:  I'm finally convincing the
> senior systems guy that Packages Are Good, and now developers for the
> upstream OS seem to be telling me Packages Are Useless, because I can't
> even count on a critical dependency being installed via the package
> system.  )

You can depend on it if you're using dependencies right.

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


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

Bug#427113: ITP: xl2tpd -- a layer 2 tunneling protocol implementation

[Roberto C. Sanchez]

Package: wnpp
Severity: wishlist
Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]>

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: xl2tpd
  Version : 1.1.09
  Upstream Author : Paul Wouters <[EMAIL PROTECTED]>
* URL : http://www.xelerance.com/software/xl2tpd/
* License : GPL
  Programming Lang: C
  Description : a layer 2 tunneling protocol implementation

 xl2tpd is an open source implementation of the L2TP tunneling
 protocol (RFC2661).  xl2tpd is forked from l2tpd and is maintained by
 Xelerance Corporation.
 .
 This package replaces the obsolete and unmaintained l2tpd.
 .
 The main purpose of this protocol is to tunnel PPP frames through IP
 networks.  It implements both LAC and LNS role in the L2TP networking
 architecture.
 .
 Homepage: http://www.xelerance.com/software/xl2tpd/


Please refer to bug 358799 [0] for more information.

Regards,

- -Roberto

[0] http://bugs.debian.org/358799

- -- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=es_ES, LC_CTYPE=es_ES (charmap=ISO-8859-1)

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

iD8DBQFGYKcQ5SXWIKfIlGQRArb/AJ9dlG+y563pQAfxkxK6keAOm+wRewCdGRRD
ij1+mKkEoYOo9NbfWun6nas=
=fIqX
-END PGP SIGNATURE-


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

Re: Filing FTBFS bugs and packages in NEW

[Roberto C . Sánchez]

On Fri, Jun 01, 2007 at 01:01:07PM +0200, Lucas Nussbaum wrote:
> 
> The problem is that it already takes time to file those bugs, and that
> there are a lots of bugs to file. For example, on May 22nd, 515 packages
> failed to build, and 240 failures have not been analyzed yet, so that's
> 240 potential RC bugs (of course, some of them might have been reported
> already by people not using collab-qa for coordination).
> 
Personally, I would rather see erroneously filed FTBFS bugs than bugs
missed getting reported.  An erroneously filed FTBFS bug can be quickly
closed by the maintainer of the package.  Especially in the case of mass
filings resulting from things like rebuilding the archive or other
cases (like the bug reporter not knowing/being able to access the stuff
in NEW), I think there should be a bit of leniency.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: Converting an svn-buildpackage repository to git

[Cameron Dale]

On 5/31/07, Cameron Dale <[EMAIL PROTECTED]> wrote:

I'm thinking of converting a subversion repository I use for one of my
debian packages to git (preferably with all history intact).

[snip]

No replies, so I brute-forced it. It's not pretty, but it works. I
posted it on the wiki:

http://wiki.debian.org/PackagingWithGit/Svn-buildpackageConversion

To summarize, dump the repository, run an AWK script on the dump, load
into a temporary repository, then use git-svnimport on that.

Cameron


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

shell and sed vs awk perl and python (Re: checklib ;)

[Oleg Verych]

* From: Manoj Srivastava
* Date: Fri, 01 Jun 2007 16:24:20 -0500

> On Fri, 1 Jun 2007 20:53:10 + (UTC), Oleg Verych
><[EMAIL PROTECTED]> said:  
>
>> Notes about original:
>> - `basename' doesn't work,
>
> Why? It seems to work perfectly fine here.
> __> basename 
> /usr/local/src/arch/packages--debian/kernel-package/kernel-package/debian/common/checklibs
> checklibs

[EMAIL PROTECTED]:/tmp/ck$ bash ./checklibs
checklibs"
[EMAIL PROTECTED]:/tmp/ck$ sh ./checklibs
checklibs"
[EMAIL PROTECTED]:/tmp/ck$ sh ./checklibs...
checklibs...
[EMAIL PROTECTED]:/tmp/ck$ bash ./checklibs...
checklibs...
[EMAIL PROTECTED]:/tmp/ck$

# I use
APPNAME="${0##*/}"
echo $APPNAME

>
>> - unlink early, rather than that "trap" bloat,
>
> You do not seem to understand what trap does.  I unlink temp
>  files the moment I am done with them.  Traps are set to handle
>  exceptions, and to clean up when those occur.

# In this case i meant something like this
#
O=/tmp/chklib_libs_dyn_symbols.sh
echo "# generated by $APPNAME" >$O
exec 4<$O 5>>$O # redirect and unlink early
rm $O; I=4; O=5

# descriptors sometimes aren't flexible, nevertheless this is one of
# the solutions for concurrency, races and unconditional killing

> Please read up on signal handling; your remark seems to indicate
>  you don't know what it is all about.

Ok ;)

>> - "progname" isn't used anyway,
>
> Right. It is standard boilerplate for my scripts; I usually use
>  it in diagnostic messages; of which none seemed to have survived into
>  production. 
>
>> - awk, perl overkill, (there could be `python' easyly ;)
>
> awk and Perl are essential packages; python would mean a
>  dependency.  I also don''t like python, so I am unlikely to add python
>  code to my build system.

Well, at least awk-style field access in the shell you can do like that:

field() {
# $1 field #
# $2 data
#
shift $1 ; echo $1
}

foo=`field 3 $bar`

>> - `objdump' can handle one file at time (and not buggy).
>
> I don't understand that comment.
> ,[  Manual page objdump(1) ]
>| SYNOPSIS
>|objdump [-a|--archive-headers] <>  objfile...
>| DESCRIPTION
>|objdump  displays  information  about  one  or  more object files. 
> `

`readelf' failed, this one is working -- no problem.

But i meant, that to get need libraries and undefined symbols from (not)
one file(s), one run of `objdump' is needed:

2>/dev/null objdump -T --private-headers -- * | sed -n -e '
# Matching needed libraries:
#,-
#|Dynamic Section:
#|NEEDED  libc.so.6
#`-
# Making output like (for further parsing, thus making unique names):
#,-
#|L=$L" libc.so.6";
#`-
/NEEDED/{
s_^[^lib]*\([^.]*\)\(.*\)$_L=$L" \1\2";_;
p;
};

# Matching needed dynamic symbols:
#,-
#|DYNAMIC SYMBOL TABLE:
#|000  DF *UND* 0148  GLIBC_2.2.5 __libc_start_main
#|...
#|000  w   D  *UND*   __gmon_start__
#`-
# Output is:
#,-
#|S=$S" __libc_start_main";
#|S=$S" __gmon_start__";
#`-
/\*UND\*/{   # prefix symbol with "||", add script
s_\([^\t ]*\)$_||S=$S" \1";_
s_[^|]*||__; # remove all up-to and marker
p;
};'

>> + i would suggest $PATH compatible EXTRA_ syntax
>
> I don't understand this comment either.

The way `EXTRA_LIBRARY_PATHS' variable is assignd, isn't it bad idea
to have compatible PATH assigments?

CHLPATH=/lib:/usr/lib:$EXTRA_LIBRARY_PATHS:
CHLPATH=`echo $CHLPATH | sed -e 's_/*:_:_g;s_:_ _g;s_/$__'`
# bad path test case: `echo /lib//:::/usr/lib///:/jj/kk/`

Anyway thanks for your feedback, i've placed chunks of the script here
for reference.




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

Re: Filing FTBFS bugs and packages in NEW

[Daniel Schepler]

On Friday 01 June 2007 05:59:14 am Kari Pahula wrote:
> I'd like to file a wishlist bug on people who file FTBFS bugs.
>
> It would be nice if you checked first whether there's a package
> pending in NEW or incoming and see if that might resolve the issue
> already.
>
> I'm looking at you, #426867.
>
> Thank you.

Sorry about that.  I usually try to search in NEW and in incoming.debian.org 
before filing those bugs, but I must have missed it in this case.
-- 
Daniel Schepler


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