Re: Lintian over sensitivity?

[Giacomo A. Catenazzi]

David Paleino wrote:

Il giorno Wed, 20 Feb 2008 18:44:13 +0200
Shachar Shemesh <[EMAIL PROTECTED]> ha scritto:


Fakeroot-ng is copyrighted (C) 2007-2008 by Shachar Shemesh

...
At least superficially, the copyright file lives up to all of the 
requirements that lintian asks for.


Lintian version 1.23.45

Changing the line to read:

Copyright (C) 2007-2008 by Shachar Shemesh

pacifies lintian, but I still think this is over sensitivity on its behalf.


Not really. AFAIK "(C)" has no legal validity, while "Copyright" and "©" have.


I really don't agree:
"(C)" is a symbol, as "ff", "fl", "..." are each one single symbol!
The same with "THIS IS ITALIC".

Many of you are too young to have learned the writing convention on
typewriter, but probably the judges know this convention a lot better
as us.
In future, with a wider adoption of Unicode and better
typewriter/vi/emacs/word-processors, "(C)" could become a
three symbols sequence, in other words: one ASCII character is
one symbol, but we are not in such world.

Anyway my reply and most of this thread is a demonstration of:
Color of the bikeshed theory ( 
http://en.wikipedia.org/wiki/Color_of_the_bikeshed )


ciao
cate


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

Re: Lintian over sensitivity?

[David Paleino]

Ciao Giacomo,

Il giorno Thu, 21 Feb 2008 10:46:35 +0100
"Giacomo A. Catenazzi" <[EMAIL PROTECTED]> ha scritto:

> David Paleino wrote:
>
> > Not really. AFAIK "(C)" has no legal validity, while "Copyright" and "©"
> > have.
> 
> I really don't agree:
> "(C)" is a symbol, as "ff", "fl", "..." are each one single symbol!
> The same with "THIS IS ITALIC".

IANAL, but I've read what I stated somewhere on the net. After some googling:

http://en.wikipedia.org/wiki/Copyright_symbol

Citation:

"Because the © symbol has long been unavailable on typewriters and ASCII-based
computer systems, it has been common to approximate this symbol with the
characters (c). However, this is not legally recognized as a symbol for
copyright."

I know Wikipedia is not a "secure source" for information, but Lars
Wirzenius posted a far more reliable link in this thread:

http://www.copyright.gov/circs/circ03.html

> Many of you are too young to have learned the writing convention on
> typewriter, but probably the judges know this convention a lot better
> as us.
> In future, with a wider adoption of Unicode and better
> typewriter/vi/emacs/word-processors, "(C)" could become a
> three symbols sequence, in other words: one ASCII character is
> one symbol, but we are not in such world.

Currently, as stated in the links above, "(C)" is not a legal symbol.

> Anyway my reply and most of this thread is a demonstration of:
> Color of the bikeshed theory ( 
> http://en.wikipedia.org/wiki/Color_of_the_bikeshed )

Lol, true :)

Ciao,
David

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


signature.asc
Description: PGP signature

Bug#466823: ITP: rush -- Ruby replacement for a shell

[Michael Schutte]

Package: wnpp
Severity: wishlist
Owner: Michael Schutte <[EMAIL PROTECTED]>


* Package name: rush
  Version : (no official release yet)
  Upstream Author : Adam Wiggins <[EMAIL PROTECTED]>
* URL : http://rush.heroku.com/
* License : (needs to be clarified)
  Programming Lang: Ruby
  Description : Ruby replacement for a shell

rush is a replacement for the traditional UNIX shell which uses pure
Ruby syntax.  Many common operations are provided as builtin methods,
like grepping, finding and killing processes, or moving and copying
files.  It can also control remote machines running rushd.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_AT.UTF-8)
Shell: /bin/sh linked to /bin/bash


signature.asc
Description: Digital signature

Re: Bug#466728: ITP: python-trio -- RDF utilities

[Lars Wirzenius]

On to, 2008-02-21 at 08:44 +0100, Christian Perrier wrote:
> Sorry, this is precisely rationale I fight against. Just saying "if you
> don't know what this is, you don't need this" defeats the purpose of
> packages descriptions. 

I completely agree. There are lots of scenarios in which one might not
be an expert in the topic for which a package is intended, but might
still need to understand what's going on. For example:

* English is not your native language, so you actually know the stuff,
but using different words.

* You install packages for someone else.

* You have an acronym clash: the XYZ in the package is some other XYZ
than the one you know, and having a verbose package description makes
you realize this before you install the package, saving everyone some
embarrassment.

* You're curious and want to learn about new things, so you trawl
through the Packages file in search of stuff you don't already know
about, which means you might learn about, oh, I don't know, new
programming languages or esoteric ham radio stuff.

These are not hypothetical cases; they've all happened to me. (I admit
that I use Wikipedia more often these days than the Packages file, but
hey, sometimes I'm offline.)



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

Ecartis command results: -- Binary/unsupported file stripped by Ecartis --

[Ecartis]

>> Q
Unknown command.

>> ÉÔ¾8sV¤’âþ”;Ì056dÏekä,BŸ‹L©Œ×›XîhÇsE‹˜<'w:«ÅÒՏ7Ç 
>> |HÐp#£|¼*(«íÌëÆYµ»n³‚ÕÒÒ½EŠ:ÓS‰
Unknown command.

>> !AóìkMŒ±Ú?k>
Unknown command.

>> —ÀÉå¯uþiÀö–ý›“ÆF‡o«›C>“À¢¿¬§Ëä^Z’í.ŒÛäâb$ÁFãÀb¥e;ñÍØ֊s.¦£ôïpŠ$)
Unknown command.

>> R9ýùhçšUo·Øã°CC-/ÑÊ¿¾©öj¾H%v¦ÝuƒÎ$
Unknown command.

>> “êoS?½k5í¢–AҜbÎTöaîÀFÐ
Unknown command.

>> ¸Ä²¨ÒùÊ[¤”ú†~82Œ-eםËó¢ðS[°ô#ðÍÞ¾eÀ®èžG{
Unknown command.

>> (ŒS5}sæ¿ô¯tž³Wí'‰‚q]Žè¯_hÝ©qÀ‡Jµï—±å»¼£üìïÏ:¹Gò׋8ß% íB(&Šëg(´D‹
>> 2௰ł})1úýÞ9í;ª›é¤Š Œ6}~voüàƒWG›ö^o¶¼³j˜î<}¹:ÎåM¤¢gh¿Ýó“Qiº¡Ôͬý
Unknown command.

>> ÐTœ6±Y£#ã›-¬¼
Unknown command.

>> Æj-rÕóä͈`¯‘3Kٓ£éütuø.
Unknown command.

>> Úb¯‹LÌÇ3ZU-yç—aôjé>‡·xGö‹HóŽämRž×ž[³u¸dõ"ÞRÌËÔþÐåsASóþ¡âµj©jƒ½›-¤’ê>ٙ¿ÖbuÉ·
>> ©!¶Ô2ÜfßAkï0­lÛ¦RŸù†“kÛö
Unknown command.

>> ÓYYƒû–íŒrÔ¶ç¥,5ûöóÉKL´WoàµzWR$…›ö»‘®‚™¦ÙíêfX{‹ õžÀìá&&ð 
>> t$LÄNCrU‹'Ph½ŠƒÉhÉÄ6A§ßÉ;¹
Unknown command.

>> VH犲gïô£?9vÕ_º_¼úòH_×“œwl
Unknown command.

>> ÐË.}úW¾L6(©‚yëúl§Ë·GØ÷¿ÛŒj{梖°
Unknown command.

>> ¼;s'BU›¡f»ï#ٖ¶k…—2õ–aݛP–¡¹|3½Øà-¸¾d¸×èâlôŸve*T;SF0U‡–Ž‡T[KŸ‹&â°ª’°c¼lƓèÌCÞÙÍ{I?¨üüöôL•LºÍ§%*ðA¡b.
Unknown command.

>> Üú» ’Wx4]ß«s>Ì*þg[«„ñcŽÛ¿5ù[ô%ª] Š¹âžÐ-ºÜàøýAü­±3º©C³˜
Unknown command.

---
Ecartis v1.0.0 - job execution complete.


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

Re: Bug#466728: ITP: python-trio -- RDF utilities

[Noah Slater]

On Thu, Feb 21, 2008 at 08:44:00AM +0100, Christian Perrier wrote:
> Sorry, this is precisely rationale I fight against. Just saying "if you
> don't know what this is, you don't need this" defeats the purpose of
> packages descriptions.

In the general case maybe but for this I disagree. For highly specialised
development tools such as RDF there is really no need to be verbose about what
the name actually means because those who would be interested already know.

I took a look at the current state of affairs w/r to RDF:

[EMAIL PROTECTED]: ~ $ apt-cache search rdf | grep rdf
liblrdf0 - a library to manipulate RDF files describing LADSPA plugins
liblrdf0-dev - liblrdf0 development files
librdf-perl - Perl language bindings for the Redland RDF library
librdf-ruby - Ruby 1.8 language bindings for the Redland RDF library
librdf0 - Redland Resource Description Framework (RDF) library
librdf0-dev - Redland RDF library development libraries and headers
php5-librdf - PHP5 language bindings for the Redland RDF library
python-librdf - Python language bindings for the Redland RDF library
python-rdflib - RDF library containing an RDF triple store and RDF/XML 
parser/serializer

Only one of these packages is expanding the acronym RDF.

I really don't see the use case here.

--
Noah Slater 


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

Re: Bug#466728: ITP: python-trio -- RDF utilities

[Noah Slater]

> I'd suggest expanding what RDF is, at least in the long description. Even
> better would be expanding it in the synopsis of course.

I disargree with you on this point. If the user doesn't know what RDF is they
certainly don't want to install the package and knowing the definition isn't
going to change much. Similarly, you wouldn't expand GTK or HTTP or NFS if the
package was providing a developer library to deal wich such things.

I agree that the description could be longer. The homepage is pretty terse and I
was planning on contacting upstream for suggestions for extended description.

--
Noah Slater 


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

Re: the new style "mass tirage" of bugs

[Raphael Hertzog]

On Wed, 20 Feb 2008, Mike Hommey wrote:
> Yeah, it must be really hard to be an heavy bug filer.
> 
> * 1552 Outstanding
> * 136 Forwarded
> * 10 Pending Upload
> * 1 Fixed in NMU
> * 69 Resolved

Note that if you look at his archived bugs you have to add:
  * 2010 Resolved

Some bugs are of dubious quality, but one must accept that in the end, it's
still impressive. :)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Re: the new style "mass tirage" of bugs

[Mike Hommey]

On Thu, Feb 21, 2008 at 02:09:11PM +0100, Raphael Hertzog <[EMAIL PROTECTED]> 
wrote:
> On Wed, 20 Feb 2008, Mike Hommey wrote:
> > Yeah, it must be really hard to be an heavy bug filer.
> > 
> > * 1552 Outstanding
> > * 136 Forwarded
> > * 10 Pending Upload
> > * 1 Fixed in NMU
> > * 69 Resolved
> 
> Note that if you look at his archived bugs you have to add:
>   * 2010 Resolved
> 
> Some bugs are of dubious quality, but one must accept that in the end, it's
> still impressive. :)

Note that also doesn't indicate how many were actually fixed. We have
nothing that look like bugzilla's NOTABUG or INVALID.

Mike


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

Re: the new style "mass tirage" of bugs

[Bernhard R. Link]

* Christian Perrier <[EMAIL PROTECTED]> [080221 08:36]:
> Or also sometimes refrain themselves of filing nitpicking bugs for
> corners cases which noone will ever meet. Or when doing thissend
> *patches*.
>
> Where resources are low, adding more noise to an already noisy pile of
> bugs is just covering dust with more dust.
>
> I don't say that ppl shouldn't file bugsI more suggest to be a
> little bit more selective when filing them.

Just for the record in case any user is reading this dicussion: This only
holds for packages too large to properly maintain it. For every package
I maintain or might maintain in the future or is small enough that there
are enough people to properly maintain it, please file all bugs you find
that are not already filed. Especially those about corner cases almost
noone runs in. (The obvious bugs I'll find myself eventually,
information about the hard to find ones is the most valueable).

> Of course, this is particularly targeted at jidanni who is very good
> for filing bugs as most of us know.

While jidanni's bugs are often hard to read and some might be plain
stupid, I got many valuables bugs about hard to spot bugs or broken
documentation. I think in the large picture he did more to improve
Debian than some maintainers only adding package after package to the
distribution.

Hochachtungsvoll,
Bernhard R. Link


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

Re: the new style "mass tirage" of bugs

[Raphael Hertzog]

On Thu, 21 Feb 2008, Mike Hommey wrote:
> > Some bugs are of dubious quality, but one must accept that in the end, it's
> > still impressive. :)
> 
> Note that also doesn't indicate how many were actually fixed. We have
> nothing that look like bugzilla's NOTABUG or INVALID.

Indeed. One could check how many of those bugs have been version-closed vs
manually closed. Because non-bugs are usually manually closed.

(Though many of jidanni's bugs probably predate the implementation of
version tracking)

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


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

Bug#466866: O: libjsw -- joystick library

[Darren Salt]

Package: wnpp

I've neglected libjsw for far too long; I just don't have any real interest
in maintaining it these days (and anyway it's ages since I last used a
joystick, and even then it was an old one with a standard DB9 connector).

searchandrescue and oxine depend on libjsw, and bug 458774 says that oxine
needs libjsw 1.56; jscalibrator should be ported to GTK+2 sometime.

This follows up discussion in -games:
http://lists.debian.org/debian-devel-games/2008/01/msg00247.html

-- 
| Darren Salt| linux or ds at  | nr. Ashington, | Toon
| RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army
|   http://www.youmustbejoking.demon.co.uk/progs.packages.html>

Double!



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

Re: the new style "mass tirage" of bugs

[John Goerzen]

On Thu February 21 2008 12:51:42 am Ben Finney wrote:
> "Paul Wise" <[EMAIL PROTECTED]> writes:
> > I'm very bad at doing this myself, but it is equally important for bug
> > submitters to triage their own bugs, especially if they have lots or
> > many old ones.
>
> It's important for bug submitters to *confirm* their own bugs,
> especially if newer versions of the package have been released.

Yes, I agree.  But I find myself on both sides of this fence.

When people submit bugs on Bacula that are upstream bugs, I rarely want to 
try to hack into it myself.  I view backup software as something akin to 
fsck: something I don't want to fsck with unless I really have to, because 
it's so important.

Sometimes a changelog entry upstream sounds like it's fixed a bug, or the bug 
has been open long enough that some major relevant piece of architecture has 
changed, and I want confirmation that it still exists before harassing 
upstream about it.

On the other hand, as a user, I may be running etch on a production server 
and have no means to validate whether some change in sid or lenny actually 
fixes things.

Here's the thing.  If bugs I submit actually get looked at by a human, and 
humans are fixing a reasonable percentage of bugs submitted, I don't mind 
testing things out on new versions whenever I can.

But if there's a blackhole where all I *ever* hear about a particular bug -- 
or even any bug on that package -- is the periodic "does it still exist?", 
well that is a really poor way to treat users.

Ignoring bug reports and then using "triage" as a way to close them after new 
releases is an abuse of the BTS.

-- John


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

Dubai Balanced Score Center

[Heba Munier]

Dubai Balanced Score Training Center 
   
Up Coming Program Mar 2008

- 
[http://www.bsdubai.org/programs_details.php?type=course&cat=510]
Strategies Of Modem Public Relations Dubai - City
Seasons Hotel - Mar 02To 06 / 2008
- 
[http://www.bsdubai.org/programs_details.php?type=course&cat=918] Moderm
Strategies To Supervise Security   Cairo - Grand Hayat Hotel - Mar
09To 13 / 2008 
- 
[http://www.bsdubai.net/programs_details.php?type=course&cat=CI%20422]
Effective Communication & Interpersonal Skills Cairo - Grand Hayat
Hotel - Mar 09To 13 / 2008 
- 
[http://www.bsdubai.net/programs_details.php?type=course&cat=SM%20720]
Introduction To Sales and Marketing  Cairo - Grand Hayat
Hotel - Mar 09To 13 / 2008  
- 
[http://www.bsdubai.net/programs_details.php?type=course&cat=HR%20234]
Train The Trainner Best Practices  Paris  - Le Meridiem
Etoile - Mar 23 To 27 / 2008 
- 
[http://www.bsdubai.net/programs_details.php?type=course&cat=PI%20542]
Advaned Contracts Management   Geneva - Prestol Hotel
   - Mar 23 To 27 / 2008
- 
[http://www.bsdubai.net/programs_details.php?type=course&cat=ML%20140]
Building High Performance Teams   Geneva - Prestol
Hotel  - Mar 23 To 27 / 2008  
Heba Munier
B.S. Center 
[mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
[http://www.bsdubai.org] www.bsdubai.org
Tel:00971509228381 
Fax:0097142638827
 

This message was sent by: Heba Munier, Al-Qusaif T-Dubai, +965-9449251, Kuwait 
56970, Kuwait

Powered by iContact: http://freetrial.icontact.com

Manage your subscription: 
http://app.icontact.com/icp/mmail-mprofile.pl?r=7709803&l=17117&s=SVON&m=100739&c=218332

Re: How to cope with patches sanely

[martin f krafft]

also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.20.1722 +0100]:
> I have to take care of it manually once.  That is the first time
>  I setup the integration branch that  merges in changes from the
>  overlapping feature branches.  This is not a big deal, because the
>  human has to spend some time disambiguating the overlap.
> 
> It is critical to me that I never have to spend that time
>  again -- and in my case, I never do, since future non overlapping
>  changes (like, say, a new upstream release) produce deltas that apply
>  to the feature and integration branches seamlessly.  I never have to
>  rethink or redo any patches.

What if feature B depends on feature A and a new upstream causes
a merge conflict in feature A. Then you have to fix feature A, which
causes a conflict with feature B. Now you have to redo the entire
integration, taking care to merge in the right order...

> > Yes, just like I want to have feature branches instead of one gigantic
> > debian branch.
> 
> I use my CSM to provide me the changeset:
>   baz  diff  

That does not help me during an NMU from the source package.

-- 
 .''`.   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
 
"work consists of whatever a body is obliged to do.
 play consists of whatever a body is not obliged to do."
 -- mark twain


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: the new style "mass tirage" of bugs

[Rene Engelhard]

Hi,
[EMAIL PROTECTED] wrote:
> With the new style of "mass tirage" of bugs,

triage.
 
> The user submits a bug;
> while (sleep 1 year) {
>   He gets a message asking him to verify if the bug still exists;
>   He perhaps especially reinstalls the package that he long ago stopped
> using &&
>   He verifies it || the bug is closed
> }
> 
> Now disposing of those piles of bugs is a breeze, and the maintainer
> needn't ever actually look once at the bug! Should cut down on
> those annoying new bugs too!

Yeah, especially with some of your useless ones.
Or for minor and wishlist bugs.

I agree that some of the bugs which where triaged in the last runs were 
obviously still there, but...

For the rest of my answer, see my answer to John.

Regards,

Rene


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

Re: How to cope with patches sanely

[James Vega]

On Thu, Feb 21, 2008 at 04:23:10PM +0100, martin f krafft wrote:
> also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
> > The difference here being that feature branches are, in my experience,
> > changes against the pristine upstream source.  The merging of different
> > feature branches is done in some integration branch.  Quilt patches are
> > a dependent series where the merging of changes is inherent in the patch
> > ordering.  Thus it's easier to get an "upstream ready" patch from $vcs
> > than from a series of interdependent patches.
> 
> ... unless feature branches interdepend and you have to store
> dependency information somewhere.

Each feature is still a separate candidate for inclusion upstream.  If
you have features A and B, which touch similar files and are therefore
interdependent *in your tree*, the patches sent upstream still need to
be a diff against their vanilla upstream source.

Either you maintain the patches purely against vanilla upstream
initially and perform your own merging when you prepare the Debian
package or you maintain dependent patches and rediff against upstream's
vanilla source before sending the patch their way.

Whether using $vcs or $patch_manager, there is going to be some manual
work to a) get a patch that is purely against vanilla upstream and/or b)
rediff B when A is accepted upstream.  You're just changing when you do
the work.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: the new style "mass tirage" of bugs

[Rene Engelhard]

Hi,

John Goerzen wrote:
> I have learned that certain well-known packages (OpenOffice, say) are bug

OpenOffice isn't in Debian. If you mean OpenOffice.org, I feel obliged to 
answer this now, because you complely underestimate a) how many people maintain 
OOo (hint: 1) and b) how many time even keeping up is.
 
> blackholes.  I submit a bug, and never hear anything from Debian
> maintainers 
> except for periodic triage stuff when a new upstream comes out.

Sorry, that's not fair at all.

> If they suspect it was upstream-related, it should have been forwarded.

And detecting this needs time. And testing.
And even then, when forwarding bugs they might lie at upstream bugtracker for 
years anyway because Sun doesn't care (and some of the long-forwarded bugs were 
included in Liors last triage if I am not wrong)

> But I can't submit OpenOffice bugs upstream because we don't use 
> OpenOffice.Org's source trees.  Sigh.

Sorry, that's not true either. You can install a plain OOo in parallel with 
some hackery (use the rpms, install to a rpm db with --force --nodeps)

> There appears to be no place for Debian users to submit OpenOffice bugs
> where 
> a human will investigate.

If you give me some time and a co-maintainer at hand...

I am barely keeping up with *new* bugreports and updating the packages, keeping 
them buildable, backporting fixes from upstream etc.

And you *have* to admit it's gone a bit better for new bugs, it's just that old 
bugs suffer, I admit, but I simply have no time to go over all of them.

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523 for a RFH open for 
looong.

Regards,

Rene


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

Re: Looking for co-maintainer for mercurial

[Ondrej Certik]

On Wed, Feb 20, 2008 at 9:10 PM, William Pitcock
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>  I'll be happy to help with this package.

Hi, I'll help with this package too, because I use Mercurial everyday.
Let's maintain it in:

http://wiki.debian.org/Teams/PythonAppsPackagingTeam

?

There are many good DD's around the "Python Applications Packaging
Team" and the "Debian Python Modules Team", because generally,
this is a Python program, so they may help with many python related issues.

Ondrej


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

Re: How to cope with patches sanely

[martin f krafft]

also sprach James Vega <[EMAIL PROTECTED]> [2008.02.21.0020 +0100]:
> The difference here being that feature branches are, in my experience,
> changes against the pristine upstream source.  The merging of different
> feature branches is done in some integration branch.  Quilt patches are
> a dependent series where the merging of changes is inherent in the patch
> ordering.  Thus it's easier to get an "upstream ready" patch from $vcs
> than from a series of interdependent patches.

... unless feature branches interdepend and you have to store
dependency information somewhere.

"Congratulations, you have just reinvented $patch_manager".

http://lists.debian.org/debian-devel/2008/02/msg00093.html

-- 
 .''`.   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
 
"violence is the last refuge of the incompetent"
   -- isaac asimov


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: the new style "mass tirage" of bugs

[Norbert Preining]

Hi all,

On Do, 21 Feb 2008, Rene Engelhard wrote:
> I am barely keeping up with *new* bugreports and updating the packages, 
> keeping them buildable, backporting fixes from upstream etc.


We from the Debian TeX Team have a very similar problem. There are about
300 bugs taken over from teTeX times into the TeX Live packages.

Our team consists of a few DD and few helpers, but of all I am currently
the only actually active one (and I myself am on permanent quasi VAC
till May).

I try to keep up with new bugs and fixing them, but there is NO way I
will *ever* find time to go through 300 bugs taken over from tetex.

I was (and am) tempted to do something similar, because I consider this
pile of dust^Wbugs just obscurring the important things. I consider
currently:
- severity = important -> fit for my time investment
- severity >= serious  -> trying to fix immediately
- severity <= normal   -> let them rod

That is the reality. Now and then I try to fix new bugs of sevrerity
normal or wishlist, but that's it.

The problem with most bugs are that submitters do not care at all to 
- try to find a solution themselves
- read other bug reports
- use google
- read the policy
- think

Sounds harsh, but that is the reality, unfortunately.


Have a lot of fun, and when I am back from the mountains expect some bug
triaging from TeX Live packages ...

Best wishes

Norbert

---
Dr. Norbert Preining <[EMAIL PROTECTED]>Vienna University of Technology
Debian Developer <[EMAIL PROTECTED]> Debian TeX Group
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
BENBURB
The sort of man who becomes a returning officer.
--- Douglas Adams, The Meaning of Liff


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

Bug#466876: ITP: naist-jdic -- free Japanese Dictionaries for ChaSen from NAIST

[Hideki Yamane]

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

   Package name: naist-jdic
Version: 0.2.0~preview1
Upstream Author: [EMAIL PROTECTED]
 Masayuki Asahara <[EMAIL PROTECTED]>
 Yuji Matsumoto <[EMAIL PROTECTED]> 
URL: http://sourceforge.jp/projects/naist-jdic/
License: BSD
Description: free Japanese Dictionaries for ChaSen from NAIST
 NAIST Japanese Dictionary is Dictionaries for ChaSen.
 .
 It is based on ipadic, but NAIST (Nara Institute of Science 
 and Technology, Japan) released it under BSD style license, 
 so it is free and can replace non-free ipadic, now.


pgpQi5XysvIMG.pgp
Description: PGP signature

Fwd: Re: the new style "mass tirage" of bugs

[Rene Engelhard]

Hi again,

> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=419523 for a RFH open > 
> for looong.

Oh, and note that I *did* reply to the offers there, but that didn't turn out 
(except Lior and and Tim Richardson with their bug triage of *OLD* bugs which I 
am very thankful for)

Regards,

Rene


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

Re: the new style "mass tirage" of bugs

[Rene Engelhard]

Hi,

John Goerzen wrote:
> > > blackholes.  I submit a bug, and never hear anything from Debian
> > > maintainers 
> > > except for periodic triage stuff when a new upstream comes out.
> > 
> > Sorry, that's not fair at all.
> 
> The two bugs I see in src:openoffice.org with my name on them are:
> 
> #420647, hanging in calc, which I confirmed was a Debian problem because I
> could not reproduce it with OOo builds on the same machine, and also had 
> another person see it

But you didn not a file - contrary to what you promised.

Which was reported against a version not anywhere anymore :/

> #418875, OOo crashing, which included a gdb backtrace

Which was reported against a version not anywhere anymore :/

> Both are over 300 days old, being submitted in April 2007.  Neither had
> any 
> comment from an OOo maintainer save for the message from Lior on Feb. 18, 

Uhm, 420647 had a comment from upstream. But now that I look over the bug 
again, it was just sent to [EMAIL PROTECTED], which of course do not reach 
you...

> Which is no longer practical, because we may no longer have the files
> around 
> or know what they were, the impacted users may no longer be with the 
> company, etc.  I would have been happy to provide maintainers with
> whatever 
> info was needed when the bug was reported and it was actively being looked

So you want to say with that that you can't test with 2.4 whether those ones 
are fixed?

> at here, but almost a year later with no non-automated correspondence
> isn't 
> a good thing.

I agree. But the baby has already fallen into the fountain as we say in 
Germany..

Regards,

Rene


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

Re: the new style "mass tirage" of bugs

[Josselin Mouette]

Le jeudi 21 février 2008 à 05:11 +0800, [EMAIL PROTECTED] a écrit :
> With the new style of "mass tirage" of bugs,
> 
> The user submits a bug;
> while (sleep 1 year) {
>   He gets a message asking him to verify if the bug still exists;
>   He perhaps especially reinstalls the package that he long ago stopped using 
> &&
>   He verifies it || the bug is closed
> }
> 
> Now disposing of those piles of bugs is a breeze, and the maintainer
> needn't ever actually look once at the bug! Should cut down on
> those annoying new bugs too!

How about giving a hand to those who maintain large packages so that
these bugs can actually be fixed?

OTOH, maybe you're just too incompetent for that.

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


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

Re: the new style "mass tirage" of bugs

[Paul Wise]

On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:

>  OTOH, maybe you're just too incompetent for that.

Insulting contributors really isn't helpful Josselin.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: the new style "mass tirage" of bugs

[Josselin Mouette]

Le vendredi 22 février 2008 à 02:10 +0900, Paul Wise a écrit :
> On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> >  OTOH, maybe you're just too incompetent for that.
> 
> Insulting contributors really isn't helpful Josselin.

Indeed, but jidanni is not a contributor.

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


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

Re: the new style "mass tirage" of bugs

[John Goerzen]

On Thu February 21 2008 9:19:14 am Rene Engelhard wrote:
> Hi,
>
> John Goerzen wrote:
> > I have learned that certain well-known packages (OpenOffice, say) are
> > bug
>
> OpenOffice isn't in Debian. If you mean OpenOffice.org, I feel obliged to
> answer this now, because you complely underestimate a) how many people
> maintain OOo (hint: 1) and b) how many time even keeping up is.

That is, of course, a problem.  I think that OOo isn't the only big package 
that is just too big for its maintainer staff to adequately keep up with 
bugs, and of course that generally isn't the fault of the maintainer staff.

I wasn't trying to say you're doing a bad job, Rene.  Just that the end 
result to the users such as myself is annoying.  And that's certainly not 
your fault if nobody is stepping up to help.

> > blackholes.  I submit a bug, and never hear anything from Debian
> > maintainers 
> > except for periodic triage stuff when a new upstream comes out.
> 
> Sorry, that's not fair at all.

The two bugs I see in src:openoffice.org with my name on them are:

#420647, hanging in calc, which I confirmed was a Debian problem because I 
could not reproduce it with OOo builds on the same machine, and also had 
another person see it

#418875, OOo crashing, which included a gdb backtrace

Both are over 300 days old, being submitted in April 2007.  Neither had any 
comment from an OOo maintainer save for the message from Lior on Feb. 18, 
2008, asking me to try to replicate this with newer versions.

Which is no longer practical, because we may no longer have the files around 
or know what they were, the impacted users may no longer be with the 
company, etc.  I would have been happy to provide maintainers with whatever 
info was needed when the bug was reported and it was actively being looked 
at here, but almost a year later with no non-automated correspondence isn't 
a good thing.

These two bugs were the primary reasons we had to switch to the OOo builds.

So I think my comment was fair.

Does it reflect badly on you?  Probably not, since you're the only person 
maintaining OOo and you've asked for help.  But I think it unquestionably 
reflects poorly on Debian.  Though of course we are a volunteer project, so 
it is what it is.  I'm just pointing out that.

> > But I can't submit OpenOffice bugs upstream because we don't use
> > OpenOffice.Org's source trees.  Sigh.
>
> Sorry, that's not true either. You can install a plain OOo in parallel
> with some hackery (use the rpms, install to a rpm db with --force
> --nodeps)

Yes, they even publish alien'd debs now.  Do you think the average Debian 
user is going to be running those, though?  We actually are using those in 
production at this point because it is easier to get the current OOo in etch 
with them, as well as bugs we experienced with the Debian builds.

> And you *have* to admit it's gone a bit better for new bugs, it's just
> that old bugs suffer, I admit, but I simply have no time to go over all of
> them.

I haven't submitted bugs on OOo recently, I don't think, because we switched 
to the OOo debs.  But I am glad to hear that.

-- John


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

Re: the new style "mass tirage" of bugs

[Petter Reinholdtsen]

[Josselin Mouette]
>> Insulting contributors really isn't helpful Josselin.
>
> Indeed, but jidanni is not a contributor.

Perhaps not, but it does not matter.  I have now idea about his
status.  But I do know that your message is read by a lot more than
jidanni, and those readers probably do not know any more about his
status as a contributor than I do, and only see two people writing on
a Debian list, where one is a Debian user and the other is a Debian
developer.  They see Debian developer (you) insulting a Debian user in
public, and it reflect badly on you and the Debian project.  It do not
reflect badly on the receiver of the insult for those of use just
following the discussion.  I urge you to refrain from such behavior.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: the new style "mass tirage" of bugs

[Stefano Zacchiroli]

On Thu, Feb 21, 2008 at 06:52:02PM +0100, Petter Reinholdtsen wrote:
> Perhaps not, but it does not matter.  I have now idea about his
> status.  But I do know that your message is read by a lot more than
> jidanni, and those readers probably do not know any more about his
> status as a contributor than I do, and only see two people writing on
> a Debian list, where one is a Debian user and the other is a Debian
> developer.  They see Debian developer (you) insulting a Debian user in
> public, and it reflect badly on you and the Debian project.  It do not
> reflect badly on the receiver of the insult for those of use just
> following the discussion.  I urge you to refrain from such behavior.

Very well written, thank you for this post.
... and, of course, full ack.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/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: the new style "mass tirage" of bugs

[Michael Biebl]

Paul Wise wrote:
> On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
>>  OTOH, maybe you're just too incompetent for that.
> 
> Insulting contributors really isn't helpful Josselin.
> 

But the same it true the other way around. Imho it's also not ok to
insult DDs publically in the way jidanni did. We are all volunteers
after all and ranting on a public mailing list doesn't help to improve
the motivation (and doesn't magically fix the bugs).

Just my 2¢,
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: the new style "mass tirage" of bugs

[Michael Tautschnig]

> Paul Wise wrote:
> > On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> > 
> >>  OTOH, maybe you're just too incompetent for that.
> > 
> > Insulting contributors really isn't helpful Josselin.
> > 
> 
> But the same it true the other way around. Imho it's also not ok to
> insult DDs publically in the way jidanni did. We are all volunteers
> after all and ranting on a public mailing list doesn't help to improve
> the motivation (and doesn't magically fix the bugs).
> 

But jidanni did not actually insult anyone, but just made a statement on the
current situation (possibly also expression his personal frustration). Our
social contract says that we must not hide problems - and indeed there is kind
of a problem, even though it's hard to blame anyone for it.

Nevertheless we should not use stop with the excuse that we are all volunteers.
Of course we are, but maybe there is something that can be done. What about the
following (happy flaming...): Let's just pick openoffice.org. Rene needs help.
It has 340 open bugs. We're somewhere around 1000 DDs. Makes 3 developers per
bug. Let's just randomly form teams of 3 from all DDs and assign a single bug to
each team. One week to submit a patch to the BTS.

There could be several positive outcomes: Many bugs get fixed or at least
somewhat acted upon. Randomly forming teams might result in new
teams/corporations for whatever else is to come. Hopefully at least one of each
team will have the necessary environment to reproduce the bug. Anotherone might
have the required knowledge of $LANG.

Well, just an idea.
Michael




pgpGdY9Llrshx.pgp
Description: PGP signature

Bug#466939: ITP: hex2bin -- Converts Motorola and Intel Hex files to binary

[Uwe Hermann]

Package: wnpp
Severity: wishlist
Owner: Uwe Hermann <[EMAIL PROTECTED]>

* Package name: hex2bin
  Version : 1.0.6
  Upstream Author : Jacques Pelletier <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/hex2bin/
* License : GPL
  Programming Lang: C
  Description : Converts Motorola and Intel Hex files to binary

Converts Motorola and Intel Hex (*.hex or *.ihx) files to binary.


Uwe.
-- 
http://www.hermann-uwe.de  | http://www.holsham-traders.de
http://www.crazy-hacks.org | http://www.unmaintained-free-software.org



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

Re: Lintian over sensitivity?

[Russ Allbery]

David Paleino <[EMAIL PROTECTED]> writes:

> IANAL, but I've read what I stated somewhere on the net. After some
> googling:
>
> http://en.wikipedia.org/wiki/Copyright_symbol
>
> Citation:
>
> "Because the © symbol has long been unavailable on typewriters and
> ASCII-based computer systems, it has been common to approximate this
> symbol with the characters (c). However, this is not legally recognized
> as a symbol for copyright."
>
> I know Wikipedia is not a "secure source" for information, but Lars
> Wirzenius posted a far more reliable link in this thread:
>
> http://www.copyright.gov/circs/circ03.html

Also, I believe the FSF's lawyers have said the same thing.

-- 
Russ Allbery ([EMAIL PROTECTED])   

Re: the new style "mass tirage" of bugs

[David Nusinow]

On Thu, Feb 21, 2008 at 10:20:42AM -0600, John Goerzen wrote:
> Does it reflect badly on you?  Probably not, since you're the only person 
> maintaining OOo and you've asked for help.  But I think it unquestionably 
> reflects poorly on Debian.  Though of course we are a volunteer project, so 
> it is what it is.  I'm just pointing out that.

This is something that's been bugging me for a while now. As our software
packages get larger and larger, we need more people to take them on. To do
this, we need more people willing to work with such large and difficult
codebases. Unfortunately, the number of these people doesn't seem to rise
at nearly the same level as the total amount of code we have to maintain in
such packages. 

We could deal with this problem if we were better at training and
recruiting people to work on such things. We've been lucky in the XSF
lately in getting enough hands to get the work done, but I don't think
there's any clear forumla from our experience that could guide other teams
to do the same. I'd love to find one though. If we could do a better job of
steering people towards these important packages rather than their vanity
package of the hour, I think everyone would benefit.

 - David Nusinow


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

dpkg-buildpackage now reorganizing debian/control Depends field??

[Kevin B. McCarty]

Hi dpkg maintainers, developers,

(Please follow up only to [EMAIL PROTECTED])

I've just noticed that packages I've built recently have had the list of
Depends reorganized into ASCIIbetical order in the generated binary
.debs.  I guess this was the next logical step after having dpkg-dev
re-order Build-Depends internally (as was discussed in #457151).

In some cases, particularly when the Depends can be satisfied by
different sets of alternatives, this change could have the effect of
changing the packages actually pulled in by apt-get or aptitude.  I will
be happy to post a couple such examples -- one hypothetical, one real --
if requested.  (They are a bit long so I'm not including them in this
email.)

I would like to re-iterate the statement of Colin Tuckley at
http://lists.debian.org/debian-toolchain/2008/01/msg00018.html
to request that in the future, it would be very nice if dpkg maintainers
(and everyone else, of course!) could warn developers in advance when
new features may cause unexpected changes in Debian package behaviors.

best regards,

-- 
Kevin B. McCarty <[EMAIL PROTECTED]>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751



signature.asc
Description: OpenPGP digital signature

avoid conf file overwrite message?

[William Francis]

I have a package that I made which does a dpkg-divert  in the
'preinst' on a couple of config files and then installs replacements
from them. However, even though the dpkg-divert has run (and I've
verified it does move it to the name I specify), I still get a message
that looks like this:

(this is similar to mine but not exact, I just grabbed it from the net
as I don't have mine handy)

Configuration file `/etc/twiki/apache.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
  D : show the differences between the versions
  Z : background this process to examine the situation
 The default action is to keep your current version.
*** apache.conf (Y/I/N/O/D/Z) [default=N] ? Y
Installing new version of config file /etc/twiki/apache.conf ...


Is there a way (short of piping in /usr/bin/yes or something similar)
to make that go away? Eventually I'll use something like puppet to
manage these files but for now this happens to be the easiest way. If
I do answer 'Y' it does indeed do what I want.

thanks,

Will


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

Re: the new style "mass tirage" of bugs

[Don Armstrong]

On Thu, 21 Feb 2008, David Nusinow wrote:
> We could deal with this problem if we were better at training and
> recruiting people to work on such things. We've been lucky in the
> XSF lately in getting enough hands to get the work done, but I don't
> think there's any clear forumla from our experience that could guide
> other teams to do the same. I'd love to find one though. If we could
> do a better job of steering people towards these important packages
> rather than their vanity package of the hour, I think everyone would
> benefit.

I think it's going to be in our long term interest to identify some
more of these packages that could use help and figure out what changes
(if any) need to be made to the BTS, documentation for those packages,
and anything else to help new people get into triaging these bugs.


Don Armstrong

-- 
It was said that life was cheap in Ankh-Morpork. This was, of course,
completely wrong. Life was often very expensive; you could get death
for free.
 -- Terry Pratchet _Pyramids_ p25

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


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

Re: avoid conf file overwrite message?

[Kumar Appaiah]

On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote:
> Is there a way (short of piping in /usr/bin/yes or something similar)
> to make that go away? Eventually I'll use something like puppet to
> manage these files but for now this happens to be the easiest way. If
> I do answer 'Y' it does indeed do what I want.

Isn't apt-get -y what you want?

HTH. Thanks.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: Bug#466939: ITP: hex2bin -- Converts Motorola and Intel Hex files to binary

[Hamish Moffatt]

On Fri, Feb 22, 2008 at 12:04:19AM +0100, Uwe Hermann wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Uwe Hermann <[EMAIL PROTECTED]>
> 
> * Package name: hex2bin
>   Version : 1.0.6
>   Upstream Author : Jacques Pelletier <[EMAIL PROTECTED]>
> * URL : http://sourceforge.net/projects/hex2bin/
> * License : GPL
>   Programming Lang: C
>   Description : Converts Motorola and Intel Hex files to binary
> 
> Converts Motorola and Intel Hex (*.hex or *.ihx) files to binary.

FWIW, you can do this with the srecord package. Despite the name, it reads 
and writes a bunch of hex formats and binary, and can convert between them
and apply various other transformations (address shift, byte swapping)
etc.

Note that I'm not objecting to your ITP, only proposing an existing
solution. hex2bin might be simpler to use, although it could probably be
implemented as a simple wrapper script on-top of srecord, and packaged
with it. You can do a hex to binary conversion with:

srec_cat  -Intel -output  -Binary


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: avoid conf file overwrite message?

[Kumar Appaiah]

On Fri, Feb 22, 2008 at 08:52:24AM +0530, Kumar Appaiah wrote:
> On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote:
> > Is there a way (short of piping in /usr/bin/yes or something similar)
> > to make that go away? Eventually I'll use something like puppet to
> > manage these files but for now this happens to be the easiest way. If
> > I do answer 'Y' it does indeed do what I want.
> 
> Isn't apt-get -y what you want?

OK, won't work if you do dpkg -i I guess. In fact, I may be wrong even
with apt, so sorry for the noise.

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036


signature.asc
Description: Digital signature

Re: the new style "mass tirage" of bugs

[Paul Wise]

On Fri, Feb 22, 2008 at 2:20 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> Le vendredi 22 février 2008 à 02:10 +0900, Paul Wise a écrit :
>
> > On Fri, Feb 22, 2008 at 2:07 AM, Josselin Mouette <[EMAIL PROTECTED]> wrote:
>  >
>  > >  OTOH, maybe you're just too incompetent for that.
>  >
>  > Insulting contributors really isn't helpful Josselin.
>
>  Indeed, but jidanni is not a contributor.

Insulting potential contributors isn't helpful either.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise

Re: avoid conf file overwrite message?

[Deepak Tripathi]

Hi

You can use

apt-get -y --force-yes apache2

Thanks
Deepak Tripathi

On Fri, Feb 22, 2008 at 9:01 AM, Kumar Appaiah <[EMAIL PROTECTED]> wrote:

> On Fri, Feb 22, 2008 at 08:52:24AM +0530, Kumar Appaiah wrote:
> > On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote:
> > > Is there a way (short of piping in /usr/bin/yes or something similar)
> > > to make that go away? Eventually I'll use something like puppet to
> > > manage these files but for now this happens to be the easiest way. If
> > > I do answer 'Y' it does indeed do what I want.
> >
> > Isn't apt-get -y what you want?
>
> OK, won't work if you do dpkg -i I guess. In fact, I may be wrong even
> with apt, so sorry for the noise.
>
> Kumar
> --
> Kumar Appaiah,
> 458, Jamuna Hostel,
> Indian Institute of Technology Madras,
> Chennai - 600 036
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFHvkIpSd75awtatOcRAiUMAJkB9Rr2Q0rQCBsTk6Izua9G5kqd9QCeK2Tn
> 95VRwpLusQh+tLX+Lp7VX9E=
> =Q0tq
> -END PGP SIGNATURE-
>
>


-- 
Deepak Tripathi
E3 71V3 8Y C063 (We Live By Code)
http://deepkatripathi.blogspot.com

Re: dpkg-buildpackage now reorganizing debian/control Depends field??

[Otavio Salvador]

"Kevin B. McCarty" <[EMAIL PROTECTED]> writes:

> In some cases, particularly when the Depends can be satisfied by
> different sets of alternatives, this change could have the effect of
> changing the packages actually pulled in by apt-get or aptitude.  I will
> be happy to post a couple such examples -- one hypothetical, one real --
> if requested.  (They are a bit long so I'm not including them in this
> email.)

Please, revert this change.

This is indeed a issue on APT. I'm willing to work on that on APT side
but it will take some time.

Packages order _is_ important for APT. It shouldn't be but currently
it does matter.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
-
"Microsoft sells you Windows ... Linux gives
 you the whole house."


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

Re: avoid conf file overwrite message?

[Steve Langasek]

On Thu, Feb 21, 2008 at 06:24:37PM -0800, William Francis wrote:
> I have a package that I made which does a dpkg-divert  in the
> 'preinst' on a couple of config files and then installs replacements
> from them. However, even though the dpkg-divert has run (and I've
> verified it does move it to the name I specify), I still get a message
> that looks like this:

> (this is similar to mine but not exact, I just grabbed it from the net
> as I don't have mine handy)

> Configuration file `/etc/twiki/apache.conf'
>  ==> Modified (by you or by a script) since installation.
>  ==> Package distributor has shipped an updated version.
>What would you like to do about it ? Your options are:
> Y or I : install the package maintainer's version
> N or O : keep your currently-installed version
>   D : show the differences between the versions
>   Z : background this process to examine the situation
>  The default action is to keep your current version.
> *** apache.conf (Y/I/N/O/D/Z) [default=N] ? Y
> Installing new version of config file /etc/twiki/apache.conf ...

> Is there a way (short of piping in /usr/bin/yes or something similar)
> to make that go away? Eventually I'll use something like puppet to
> manage these files but for now this happens to be the easiest way. If
> I do answer 'Y' it does indeed do what I want.

Diverting conffiles is not supported.  Suppressing the prompts is supported
with a dpkg option; one of --force-confnew, --force-confold, or
--force-confdef, depending on which default you want to use.  (It's possible
to configure dpkg options in /etc/apt/apt.conf, though I don't remember the
incantation exactly.)

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Re: liblockfile L_PID behavior and use of stat atime

[Rob Browning]

Rob Browning <[EMAIL PROTECTED]> writes:

> Someone reported a bug against lockfile-progs, and while
> investigating I noticed a couple of things about liblockfile that
> didn't seem quite right.

After further investigation, it looks like a lockfile created on a
noatime (or relatime?) filesystem, without specifying L_PID, can never
go stale.  The problem is in lockfile_check().

Does anyone have any bright ideas about how to fix that?

One suggestion was to just test in lockfile_check() to see if the
atime changes between two accesses, but that would require sleeping
for "long enough" between the attempts.  Of couse how long is long
enough would depend on the atime resolution of the underlying
filesystem.

I suppose that approach would fix the problem, but would it be
acceptable to slow down lockfile_check(), lockfile_create(), etc. by
that much, and if so, how could you portably and quickly determine the
atime resolution?  I have the impression that for some filesystems,
the resolution can be fairly coarse.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


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

Practical solutions to: the new style "mass tirage" of bugs

[John Goerzen]

[ subject changed ]

On Thursday 21 February 2008 8:22:49 pm Don Armstrong wrote:
> On Thu, 21 Feb 2008, David Nusinow wrote:
> > We could deal with this problem if we were better at training and
> > recruiting people to work on such things. We've been lucky in the
> > XSF lately in getting enough hands to get the work done, but I don't
> > think there's any clear forumla from our experience that could guide
> > other teams to do the same. I'd love to find one though. If we could
> > do a better job of steering people towards these important packages
> > rather than their vanity package of the hour, I think everyone would
> > benefit.
>
> I think it's going to be in our long term interest to identify some
> more of these packages that could use help and figure out what changes
> (if any) need to be made to the BTS, documentation for those packages,
> and anything else to help new people get into triaging these bugs.

Excellent points made by both of you.

Here are some things that occur to me quickly:

1) Large projects using $DVCS and making it easy for people that aren't 
familiar with $DVCS to learn how to participate in that project.  Here I 
assume $DVCS to be one of hg, git, darcs, bzr.  The "maintainer of record" 
in control could be a Linus-like patch reviewer.  The instructions are 
something akin to what I post at 
http://software.complete.org/site/wiki/DarcsGuide and 
http://software.complete.org/site/wiki/MercurialGuide

2) Potential ways to assign bugs to particular contributors or subprojects 
that don't occur at binary package boundaries.

3) Even better, ways to let that happen at submission time.

4) Integration with BTS and $DVCS.  I have some code that marks bugs pending 
when mentioned in a VCS change log.  But this could go farther: branches 
tied to bugs, etc.

5) A way of sorting bugs by "hack on this first".  Our priorities are not 
necessarily this way. For instance, we may have a wishlist bug to package 
the new upstream and a serious bug that is caused by a bug in the current 
upstream and may be fixed by the new upstream.  Makes sense to do the 
wishlist bug first and then test to see if it's gone away.  In a sense, we 
need a field that means nothing to anybody except the maintainers, and is a 
value that the maintainers can use for whatever purpose they like.

6) Better tools to integrate Debian BTS with upstream BTS.  I would love a 
command-line tool where I could say "debforward 123456".  It would look up 
the package name for 123456, figure out from some metadata what type of BTS 
it uses and where it lives, look up my account on that BTS in ~/.forward, 
and create a bug report there and mark the Debian one forwarded.  Then, if 
there is no automated mechanism, some scanner at Debian would look for 
changes on either end and forward them back and forth.  I would love this.

It takes a *ton* of time to interact with some HTTP-only BTSs and forward 
stuff back and forth.

7) Perhaps even a change of policy on upstream bugs.  If the Debian 
maintainer is really sure a bug is upstream, it should be a valid response 
to close it in Debian with instructions on submitting it upstream and 
reopening it in Debian if upstream believes it's a Debian issue.  There's a 
lot of work just schlepping data between upstream and end users for things 
that aren't really Debian issues.

Take this with a grain of salt, as I don't actually maintain any packages of 
the scale of OOo/KDE/whatever.  Just one that feels big to me. :-)

-- John

Side note: "schlepping" appears to be in KDE's dictionary.  wow.  
Strangely, "KDE's" isn't.


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

Re: the new style "mass tirage" of bugs

[Russ Allbery]

David Nusinow <[EMAIL PROTECTED]> writes:

> This is something that's been bugging me for a while now. As our
> software packages get larger and larger, we need more people to take
> them on. To do this, we need more people willing to work with such large
> and difficult codebases. Unfortunately, the number of these people
> doesn't seem to rise at nearly the same level as the total amount of
> code we have to maintain in such packages.

> We could deal with this problem if we were better at training and
> recruiting people to work on such things. We've been lucky in the XSF
> lately in getting enough hands to get the work done, but I don't think
> there's any clear forumla from our experience that could guide other
> teams to do the same. I'd love to find one though. If we could do a
> better job of steering people towards these important packages rather
> than their vanity package of the hour, I think everyone would benefit.

There are two specific difficulties that I've seen that I think contribute
heavily to the ever-growing bug list problem:

* For large, complex projects, a lot of the bugs that don't get answered
  are of the form "I tried to do X, Y, and Z with this package and it
  didn't work or crashed," usually with the crash happening under obscure
  or mysterious circumstances, without good information about what
  happened prior to the crash or mistaken behavior, and often involving
  obscure features of the package.

  These bugs are very hard.  Unless you know the code very well and can
  make educated and lucky guesses at where the problem might be and how to
  narrow it down, they are exceedingly difficult to reproduce in a
  reasonable length of time.  Furthermore, working for four or eight hours
  to try to set up a test environment suitable for reproducing and fixing
  an obscure bug is not interesting or rewarding work compared to
  packaging new software or working on ten other bugs that can be fixed in
  15-30 minutes each.

  These sorts of bugs often are abandoned even for commercial products.
  When they aren't, it's because someone is paid (via customer support
  contracts) to do the tedious work of reproducing bugs no one really
  wants to look at as a hobby.  (It doesn't help that over half the time,
  the problem ends up being some misconfiguration or other issue where the
  only real change that can be made in the software is better error
  handling.)

* Training people on how to contribute to a free software project, triage
  bugs, write maintainable code, and fix problems appropriately is hard
  work.  I have a difficult time devoting enough time and energy to
  mentoring as part of my regular job, and there I'm being paid to do it
  and measured on it in performance reviews.  It is sad, but nonetheless
  true, that when I sit down to work on Debian in the evenings or on the
  weekends as a hobby, often the last thing I want to do is try to walk
  other people through learning how to program and do software
  maintanence.  That's *work*; I want to do something immediately
  rewarding, like writing code and fixing bugs.

  Some people really like mentoring and training others and find that
  immediately rewarding.  Those people are wonderful and deserve all the
  praise we can give them.  For the rest of us, I think it's often a lot
  to expect of people.  That sort of training is in many respects
  significantly harder than all the rest of what one does as a DD.  It can
  be a lot of fun with just the right person and a great match of
  personalities, but on a comprehensive, project-wide basis, you can't
  rely on that match happening.  In a workplace, you simply have to make
  training happen even if it isn't loads of fun for both people.  It's
  much harder to do that as part of a volunteer project.

Not every bug falls into the first category, and I think many projects in
Debian do a great job with training.  I'm not saying that the above
explains everything.  But if you look across all of the bugs of some of
our large projects that have hundreds of bugs, I think that you'll find a
significant number of bugs in that first category where people just don't
have the time, energy, or desire to do the work required to resolve them.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: the new style "mass tirage" of bugs

[Michael Tautschnig]

[...]
>   Some people really like mentoring and training others and find that
>   immediately rewarding.  Those people are wonderful and deserve all the
>   praise we can give them.  For the rest of us, I think it's often a lot
>   to expect of people.  That sort of training is in many respects
>   significantly harder than all the rest of what one does as a DD.  It can
>   be a lot of fun with just the right person and a great match of
>   personalities, but on a comprehensive, project-wide basis, you can't
>   rely on that match happening.  In a workplace, you simply have to make
>   training happen even if it isn't loads of fun for both people.  It's
>   much harder to do that as part of a volunteer project.
>
[...]

Do you think that there is a chance we find a group of people who really like
mentoring/training others? If so, we could maybe set up kind of a bug-frontdesk
taking over _all_ new bug reports for a moment and checking them for a the bit
of information that seems crucial to fix/reproduce the bug.

Well, just another idea.
Michael



pgpjReEeT1VWA.pgp
Description: PGP signature

Re: the new style "mass tirage" of bugs

[Charles Plessy]

Le Thu, Feb 21, 2008 at 10:54:09PM +0100, Michael Tautschnig a écrit :

> What about the following (happy flaming...): Let's just pick
> openoffice.org. Rene needs help.  It has 340 open bugs. We're
> somewhere around 1000 DDs. Makes 3 developers per bug. Let's just
> randomly form teams of 3 from all DDs and assign a single bug to each
> team. One week to submit a patch to the BTS.

Hi all,

Similar to the BSP model, bug triaging parties could also provide nice
opportunities to do that kind of effort in synergy, (and to socialise
afterwards).

Have a nice day,

-- 
Charles Plessy
http://charles.plessy.org
Wakō, Saitama, Japan


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

Re: Practical solutions to: the new style "mass tirage" of bugs

[Steve Langasek]

On Thu, Feb 21, 2008 at 11:31:32PM -0600, John Goerzen wrote:

> Excellent points made by both of you.

> Here are some things that occur to me quickly:

> 1) Large projects using $DVCS and making it easy for people that aren't 
> familiar with $DVCS to learn how to participate in that project.  Here I 
> assume $DVCS to be one of hg, git, darcs, bzr.  The "maintainer of record" 
> in control could be a Linus-like patch reviewer.  The instructions are 
> something akin to what I post at 
> http://software.complete.org/site/wiki/DarcsGuide and 
> http://software.complete.org/site/wiki/MercurialGuide

Are we still talking about OOo here?

OOo is its own barrier to entry.  You're not going to get a very
"distributed" set of contributors when just building the package from source
requires setting aside multiple GB of disk and several hours of CPU time.  I
believe that, as much as anything, is why there are so few people working on
the Debian package; it's just not practical to be a casual contributor to a
monolithic package like OOo.

-- 
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/
[EMAIL PROTECTED] [EMAIL PROTECTED]


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

Work-needing packages report for Feb 22, 2008

[wnpp]

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

Total number of orphaned packages: 357 (new: 65)
Total number of packages offered up for adoption: 90 (new: 5)
Total number of packages requested help for: 35 (new: 0)

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



The following packages have been orphaned:

   ada-mode (#465891), orphaned 6 days ago
 Description: Ada mode for GNU Emacs and XEmacs
 Installations reported by Popcon: 100

   attal-themes-medieval (#465965), orphaned 6 days ago
 Description: medieval theme for attal
 Reverse Depends: attal
 Installations reported by Popcon: 236

   autogen (#466329), orphaned 4 days ago
 Description: an automated text file generator
 Reverse Depends: autogen libopts25-dev
 Installations reported by Popcon: 1902

   chatbot-eliza (#465879), orphaned 6 days ago
 Description: Eliza chat bot interface module for Perl
 Installations reported by Popcon: 89

   colormake (#465892), orphaned 6 days ago
 Description: simple wrapper around make to colorize output
 Installations reported by Popcon: 521

   cronolog (#465934), orphaned 6 days ago
 Description: Logfile rotator for web servers
 Reverse Depends: gforge-web-apache2
 Installations reported by Popcon: 282

   dbishell (#465851), orphaned 6 days ago
 Description: Interactive SQL shell with readline support
 Installations reported by Popcon: 850

   dep.pl (#465899), orphaned 6 days ago
 Description: The dependency analyst
 Installations reported by Popcon: 51

   docbook-xsl-stylesheets-ko (#465992), orphaned 6 days ago
 Description: Stylesheets for processing DocBook XML files to HTML
   and FO in korean.
 Installations reported by Popcon: 42

   f2c (#465909), orphaned 6 days ago
 Description: A FORTRAN 77 to C/C++ translator.
 Reverse Depends: fort77 octave2.1-headers octave2.9-headers
 Installations reported by Popcon: 831

   fortunes-debian-hints (#465936), orphaned 6 days ago
 Description: Debian Hints for fortune
 Installations reported by Popcon: 1289

   freesweep (#465927), orphaned 6 days ago
 Description: a text-based minesweeper
 Installations reported by Popcon: 122

   fujiplay (#465893), orphaned 6 days ago
 Description: Interface for Fuji digital cameras
 Installations reported by Popcon: 67

   gcal (#465930), orphaned 6 days ago
 Description: Prints calendars
 Installations reported by Popcon: 346

   gnurobbo (#465941), orphaned 6 days ago
 Description: GNU Robbo is logic game ported from ATARI XE/XL
 Installations reported by Popcon: 134

   grcm (#465890), orphaned 6 days ago
 Description: GNOME application to initiate connections to remote
   machines
 Installations reported by Popcon: 151

   groundhog (#465949), orphaned 6 days ago
 Description: A simple logic game
 Installations reported by Popcon: 127

   hnb (#465888), orphaned 6 days ago
 Description: Hierarchical notebook
 Installations reported by Popcon: 215

   html-munger (#465881), orphaned 6 days ago
 Description: Module which simplifies the creation of web filters.
 Installations reported by Popcon: 46

   ikvm (#466336), orphaned 4 days ago
 Description: Java virtual machine/compiler implemented in .NET
   (Mono)
 Reverse Depends: ikvm
 Installations reported by Popcon: 109

   jailtool (#465905), orphaned 6 days ago
 Description: Tool to build chroot-jails for daemons
 Installations reported by Popcon: 100

   joystick (#465928), orphaned 6 days ago
 Description: Testing and calibration tools
 Installations reported by Popcon: 639

   kdrill (#465962), orphaned 6 days ago
 Description: A Kanji drill and dictionary program
 Installations reported by Popcon: 82

   knetfilter (#465898), orphaned 6 days ago
 Description: GUI for configuring the 2.4 kernel IP Tables
 Installations reported by Popcon: 323

   kxdocker (#465913), orphaned 6 days ago
 Description: innovative docker for KDE that is like Mac OSX Docker
 Reverse Depends: kxdocker-data
 Installations reported by Popcon: 347

   kxdocker-data (#465914), orphaned 6 days ago
 Description: resource files for kxdocker
 Installations reported by Popcon: 244

   lgc-pg (#465943), orphaned 6 days ago
 Description: LGeneral Converter for Panzer General
 Installations reported by Popcon: 59

   lgeneral (#465942), orphaned 6 days ago
 Description: A "Panzer General" - like game
 Installations reported by Popcon: 174

   libapache-dbilogconfig-perl (#465858), orphaned 6 days ago
 Description: Apache::DBILogConfig: Logs access information in a DBI
   database
 Installations reported by Popcon: 73

   libdata-