Bug#296714: ITP: freepop -- game inspired by the classic Populous series

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: freepop
  Version : 0.6.0
  Upstream Author : Brendon Higgins <[EMAIL PROTECTED]>
* URL : http://freepop.sf.net/
* License : GPL
  Description : game inspired by the classic Populous series

 FreePop is a multi-platform tile-based game based on the great old game
Populous 2 by Bullfrog Productions Ltd., but much improved.

 Hope you'll like it. It requires the clanlib0.7 packages currently
stuck in NEW[1], so don't expect the upload too soon. I'll put them up
on my own webpage at <http://alfie.ist.org/debian/freepop/> for the
meantime when I'm ready with packages available for testing. I'm
stumbled into a compile problem though yesterday which I have to address
with upstream first.

 So long,
Alfie
[1] But also available at <http://people.debian.org/~fenio/clanlib/>
-- 
 You never learn anything  |   /"""""\  ,'~~.
   by doing it right.  |  / chaos \  http://alfie.ist.org   |o ?~\
   -- unknown  |  \inside!/  mailto:[EMAIL PROTECTED]  /_   ~<\
   |   \_/  \__,~ \>


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

Bug#344771: ITP: spl -- SPL Programming Language interpreter and tools

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: spl
  Version : 0.9c
  Upstream Author : Clifford Wolf <[EMAIL PROTECTED]>
* URL : http://www.clifford.at/spl/
* License : GPL
  Description : embeddable programming language

 From README:
SPL is an embeddable programming language with a wide range of features:

   * complete stateful. It is at any point possible to interrupt
 a running SPL script, dump its entire state to disk and resume
 later on.

   * feature-rich. SPL has native support for hashes and arrays, regular
 expressions, object oriented programming, etc.

   * dynamic. SPL is a fully dynamic language - with all the advantages
 and disadvantages.

   * c-style syntax. SPL has a c-style syntax (as well as many other
 languages such as Java, JavaScript, PHP, slang, etc). so it is easier
 to get started.

   * advanced string lexing. SPL allows the programmer to simply embed
 variables and complex expressions in strings and template files. E.g.
 this is very important for rapid development of web applications.

   * well-structured backend. The SPL runtime is not just one big
 blackbox. Instead, there is a clear and visible seperation of
 compiler, assembler, optimizer, virtual machine, etc. This makes it
 possible to easily adapt the library for your special needs when
 embedding it in your applications.

   * more, more, more,..

 No, this won't become the long description, but I'll write that later
when I do the package for real. :)

 So long,
Alfie
-- 
  * TEST
 -- Ryuichi Arafune, changelog.Debian for imagemagick (4:5.4.6-4)


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

Bug#344772: ITP: qcake -- programming environment and scene editor for 3D games

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: qcake
  Version : 0.5.7.1
  Upstream Author : Harald Krippel <[EMAIL PROTECTED]>
* URL : http://www.qcake.org/
* License : GPL
  Description : 3D game designer

 QCake (GPL) is a programming environment as well as a scene editor for
 3D games based on PLIB ^(TM). QCake will support almost all PLIB
 functions.

 So long,
Alfie
-- 
Er:  "Ich glaub, SuSE will mich verarschen..."
Ich: "Warum nimmst auch SuSE?"
Er:  "... weil die CDs 'rumg'legen sind."
  -- 2001-03-13


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

Re: [ad-hominem construct deleted]

[Gerfried Fuchs]

* Sami Haahtinen <[EMAIL PROTECTED]> [2006-01-14 18:20]:
> I can understand that a part of the people behind Debian feel hostile
> against Ubuntu because it's succeeding in something that Debian was
> trying to achieve.

 It's not about succeeding. It's about false statements all the time,
like "Every Debian developer is also an Ubuntu developer."  If I were I
would know. And they are recompiling all my packages, so you can't even
say that they are using my packages directly.

 It's also about false statements like "We sync our packages to Debian
regularly," because that simply doesn't happen for quite a lot of us,
otherwise all these heated discussions wouldn't happen.

 These two very statements are on the very page that were linked in this
very misguided mail this fuss is all about.

> But what i can't understand is that people behind Ubuntu are trying to
> reach out and build a bridge between the people in Debian and some
> people are intentionally trying to burn them.

 I can only speak for myself (like everyone anyway, but it seems to be
mentioned), I haven't noticed anyone reaching me, so I hadn't had any
chance to burn anyone. The only contact with respect to Ubuntu was a
user disappointed that one of my packages in Debian had a fix that the
one in Ubuntu hadn't... for several weeks. All I could do is thank him
for appreciating my work but that it's out of my hands to fix it for
Ubuntu because I never was notified about that it's included there, and
wouldn't know at all who to contact therefore.

> They are really investing time on the co-operation,

 If they were, why would there be so much fuss about it? Again, speaking
for myself, I haven't noticed such a thing for myself, and there
wouldn't be the need for utnubu if there were, don't you think so?

> they are creating tools to help this. What are the Debian people
> doing, they are bitching about Ubuntu people not putting their backs
> in to it.

 Why should I pull something from Ubuntu? And find most of the time that
there isn't anything to pull? Why does it work for Debian that Debian
notifies its Upstream Developers, but not for Ubuntu to notify its
Upstream Developers, which in this case is Debian?

> I don't mean that there is no effort on Debian side either, but the
> visible effort (mostly because stunts like this) is mostly on the
> burning side.

 And not even that seems to make them show that there is something going
wrong. So what  *shrugs*

> It takes less effort to bitch and moan than to work together, maybe
> that's the reason.

 I ask you: Why should I try to work together with someone who didn't
had at least the sign of coursey to notify people they base their work
on about what they are doing, or at least _that_ they are doing it? If I
don't know that they are doing it, why should I get the idea about that
it might be a good idea to work with them? I know what of my packages
are in Debian, and everyone can get a list quite easily through several
different interfaces. In the mail this fuss is all about there is only
one huge list which does have only package names, no maintainer, no
nothing that allowes for easy usage of that list. It might be useful for
people maintaining one single package, but for people with 10 or more
it's getting annoying to have to pull the data out from there

 So long,
Alfie
-- 
"Die Angabe des vollständigen Realnamens erleichtert die Kommunikation
im Usenet ungemein, man kann sich dann nämlich auf die Inhalte der
Postings konzentrieren und muß nicht über Sinn/Unsinn von Pseudonymen
o.ä. diskutieren." (Ingo Ließegang, de.newusers.questions, 6.10.1999)


signature.asc
Description: Digital signature

Re: [ad-hominem construct deleted]

[Gerfried Fuchs]

* Sami Haahtinen <[EMAIL PROTECTED]> [2006-01-15 11:27]:
> Gerfried Fuchs wrote:
>>  It's also about false statements like "We sync our packages to Debian
>> regularly," because that simply doesn't happen for quite a lot of us,
>> otherwise all these heated discussions wouldn't happen.
> 
> They have their own timetable. They do their stabilization differently
> than debian does. Ubuntu freezes the packages at a certain point in time
> and only does manual syncs after that. "Regularly" could be once a year
> and still be regular.
> 
> What do you want? decide which packages get to certain ubuntu release?
> Didn't they just offer you that chance?

 I want that they inform their upstream about changes they do to their
releases. This is what this whole fuzz is about. And I'm not the only
one. Why should some upstream developers who don't even know that they
are forked look around the net to find things that might be useful to
them? Shouldn't rather the people that fork try to get the changes back
into their upstream, to _ease their own work_? I mean... if they want to
keep their patches forever and want to stumble into problems every now
and then for taking a look why the patch doesn't apply anymore it's fine
with me. But, they are saying that "they" sync it back, not that I would
have to run around to most of the time find nothing That's not the
way it's supposed to work.

 What I want: If someone changes something, they are on the call anyway.
They know already that they changed something, what's so difficult to
inform the involved parties? Especially as long as they keep the
Maintainer field intact and let it look like the changes were done by
me? Yes, it's in the changelog, but keeping the Maintainer means that I
am still maintaining their fork, which I simply don't do since I have no
access to upload there.

> As i see it utnubu is the middle ground for debian and ubuntu people.
> It's something that debian people want to do to keep up with Ubuntu.

 Yes, because Ubuntu isn't able or willing or whatever to keep up with
Debian. It's still working the wrong way round, it's sort of
reverse-engineering for hardware, because they know what they changed
already, we have to work it out at first, just to find most of the
time... nothing.

> I see utnubu as a good thing, it solves problems that the people behind
> utnubu want to get solved. They decided to do the work instead of
> throwing it back to Ubuntu and saying "It's your problem to make me
> agree with you". As utnubu page says:
> "We are about cooperation, not confrontation, with Ubuntu."

 It's not about agreeing. It's about working on stuff that is unique in
the Free Software community: The people who are confronted with changed
things have to actively pull the changes back, not the way around it
works like everywhere else: That people who change something push it
back.

> co-operation needs co-operation from both parties!

 Again, like I mentioned, I never was addressed about cooperation, so I
never had the chance to turn it down. And I am very sure I'm not the
only one in that state.

> You are not forced to pull anything from Ubuntu.

 Uh? But this is what it is all about. I _am_ sort of forced because
they don't push their changes, like it would rather be expected.

> But you should remember that the packages that are being worked on
> outside of the ubuntu main are maintained by a small group (when
> compared to the people in debian) of people. They have limited time to
> push all changes to upstream and usually the changes are just for the
> packaging anyway.

 If they have limited time it should be in _their own_ interest to push
the changes back. Hell, have you never stumbled upon a patch that simply
doesn't apply anymore? It's a lot of work to take a look what's going
wrong now again, whereas it is next to no work sending a small mail with
"I changed this or that, maybe you'd like to take a look at it." It's
about investing into the future, but some people only seem to work only
for today. That's also the reason why we have so many duplicated
security advisories because people don't think about the future but only
copy stuff because it's the easier approach for now

> Also, you should remember that there are people that have said that they
> don't want to be in contact with ubuntu.

 So this counts for everyone now? I don't think that the people that
have said that they don't want to be in contact with ubuntu are the ones
complaining about not hearing from them. This would be very strange,
don't you think so?

> So it's not an easy thing to notify debian people about the changes in
> their pa

Re: [ad-hominem construct deleted]

[Gerfried Fuchs]

* Matt Zimmerman <[EMAIL PROTECTED]> [2006-01-16 15:39]:
> On Sun, Jan 15, 2006 at 02:59:58AM +0100, Gerfried Fuchs wrote:
>>  It's not about succeeding. It's about false statements all the time,
>> like "Every Debian developer is also an Ubuntu developer."  If I were I
>> would know. And they are recompiling all my packages, so you can't even
>> say that they are using my packages directly.
> 
> Is the meaning of this statement truly unclear to you, or is this purely a
> rhetorical point?  Under the assumption that you read it differently than I
> do, I'll attempt to explain.

 Do we call RMS a Debian developer? Do we call Linus a Debian Developer?
Does anyone seriously consider that?

 Pardon, but that's ridiculous. I don't have upload permission at all,
can't do anything about my packages, there are changed packages with
still my name as maintainer that I never got any information about --
and you still have the guts to call me a Ubuntu developer? Sorry for
laughing into your face for that...

>>  It's also about false statements like "We sync our packages to Debian
>> regularly," because that simply doesn't happen for quite a lot of us,
>> otherwise all these heated discussions wouldn't happen.
> 
> Given that you saw this on a wiki page, a disclaimer about wiki contents
> should be implicit.

 It's still as cite from Mark on there, and I don't think that the cite
is wrong. Or do you rather consider your fellow developers putting false
statements intenionally there?

> However, regardless of whether it's an accurate quote, it's quite
> clear to me from context that your interpretation doesn't match the
> text.

 My interpretation of "regularly" and "sync" and _especially_ the "We"
most hopefully doesn't vary very much with that of most people.

> The full quote is "We sync our packages to Debian regularly, because
> that introduces the latest work, the latest upstream code, and the
> newest packaging efforts from a huge and competent open source
> community. Without Debian, Ubuntu would not be possible."  It should
> be obvious from the remainder of the sentence that it is talking about
> propagation of changes *from* Debian *to* Ubuntu.

 Then I guess the to should be changed into a from, just to get the
direction where the sync really happens and what you are willing to
really do straight with the reality.

> It was inappropriate for this user to raise this issue with you,
> rather than with Ubuntu, but that's been discussed elsewhere in this
> thread already.

 So? There is the Maintainer field that still has my name and my email
address in it as being responsible for that very package -- where I
can't do anything against it. That's simply wrong.

> What I find interesting about your statement is that you seem to imply
> that the situation would have been better if you had been notified
> that your package was a part of Ubuntu.

 Then I would had been able to a.) check if someone might add changes,
b.) to check if my address and name is in the changed package, and c.)
inform the person at hand that I don't think that the changes make much
sense and if there are changes needed for ubuntu that they should at
least have the courtsey to leave me out of the Mainainer field, becasue
again: _I_ can't do anything for the package in ubuntu. I have no upload
rights there.

 Yes, the situation would had been _immensly_ been better. It would had
shown at least that Ubuntu cares for its upstream.

> This would be technically simple to implement, but I'm not convinced
> that it's possible to do it in a socially acceptable way.  Emailing
> every Debian maintainer to notify them that their package is present
> in Ubuntu sounds like spam to me, and posting Ubuntu-related
> announcements to Debian mailing lists has been deemed inappropriate by
> many in Debian as well.

 From first I knew only that there is this Ubuntu which goes for one CD
with gnome and xorg on it. I thought fine, I don't have a package in
that range, so why should it bother me too much, so I didn't check. Do
you really think that everyone in Debian is aware that there exist a
thing like multiverse or whatever which seems to include every single
package that is in Debian? I wasn't, for a very long time. An announce
along that lines instead of a press release so you can add d-d-a to your
announce lists would hadn't stirred up so much bad blood, don't you
think so?

> The creation of Ubuntu was *very* widely publicized, as was the fact
> that it was based on Debian, and this fact has been mentioned
> countless times since, both in the press and on Debian mailing lists.

 But it wasn't really mentioned tha

Re: [ad-hominem construct deleted]

[Gerfried Fuchs]

[EMAIL PROTECTED], if you read that: Fix your mail setup, I'm not
 interested in getting double mails from whatever setup you have there.
 Thanks]

* Matt Zimmerman <[EMAIL PROTECTED]> [2006-01-17 11:36]:
> On Tue, Jan 17, 2006 at 06:46:26PM +0100, Gerfried Fuchs wrote:
>>  Do we call RMS a Debian developer? Do we call Linus a Debian Developer?
>> Does anyone seriously consider that?
> 
> Kennedy wasn't a citizen of Berlin, either, not literally.  The world
> understood what he meant, though, when he said (somewhat awkwardly) that he
> was.

 Again my question: Do you seriously consider calling Linus and RMS
Debian Developers? Even when you know exactly what this term refers so?
Tell me why I should think that a derivated Debian distribution doesn't
seem to be aware of the definition of this term within Debian.

 Sorry, Matt, but that does show to me that you aren't aware of the
difference of these statements, which very much they are.

>>  Pardon, but that's ridiculous. I don't have upload permission at all,
>> can't do anything about my packages, there are changed packages with
>> still my name as maintainer that I never got any information about --
>> and you still have the guts to call me a Ubuntu developer? Sorry for
>> laughing into your face for that...
> 
> It isn't productive to take this kind of jeering tone.

 So you want to turn down this honest (and yes, I admit emotional
driven, though still honest) question with such a statement? Do you
really call people Ubuntu developers who don't have a real chance to do
anything about what it is done to their packages and aren't informed
about such actions? Please don't avoid this question again, because it
is there.

> I'm saying that you should pause and consider that you're looking at a
> world-writable resource before treating its contents as a position statement
> on behalf of the project, and that malicious intent is far from the only (or
> even the most common) reason for errors.  It could very well be that Mark or
> someone else originally wrote "from Debian" and the quote was transcribed
> incorrectly.

 Then pretty please fix it.

> In any case, as I said, I think the meaning of the sentence as a whole is
> sufficiently unambiguous, though for the sake of clarity I will ask Mark to
> look and correct it if appropriate.

 It isn't. The difference between to and from is a thing that is very
much a difference. Because the to is the thing that isn't really
working, or do you really think there would be so much fuss if the sync
from Ubuntu back to Debian would really work?

> This had been commonplace for Debian derivatives for years before Ubuntu
> existed, and when the issue was raised regarding Ubuntu, I asked for input
> from the Debian community as to what to do.  The issue is not at all
> obvious, and in fact it's quite similar to the attribution of upstream
> authors of packages which are modified in Debian, which is even older.

 I don't know what was done for years, but I know for one thing that I
was never contacted about changes to packages and if I'd approve them.
Leaving my name in their as maintainer for a _changed_ package implies
to some degree that I'm sort-of approving it. Either by being MIA
through an NMU, through some team maintenance or similar. I can't do
anything to revert such changes (no matter how good or bad I consider
them) in packages in Ubuntu. I'm not responsible for the package in
Ubuntu, so why should my name be in there?

 About the reasoning "others have done that, too", that is mainly used
in kindergardens, I don't buy it. It sounds like a very cheap excuse. We
aren't discussing others (and yes, I would have raised the same concerns
there too, if I would have been made aware of it), we are discussing
Ubuntu.

> I haven't a clue what you're talking about here.  What press release, and
> how does d-d-a enter into it?

 You do read d-d-a, don't you? I am refering to buxy's mail, which
stirred this all up.

> If you had doubts about which packages were included, it wouldn't have
> taken much effort on your part to find out.

 So again you are saing it's the Debian Developer's job to look around
and do what would had been so easy for Ubuntu, to inform the maintainers
of packages, maybe only those that were changed upon?

> Do you truly see this as such a radical departure from how Debian and other
> distributions already work?

 Yes, I do.

> Free software is rarely so clear-cut.  By the time a piece of free
> software arrives in the hands of a user, it has passed through more
> than one set of hands and more often than not, modified from its
> original version.

 But then the people who change it don't pu

Re: [ad-hominem construct deleted]

[Gerfried Fuchs]

[don't be confused about the To header, this is merly just for testing a
 propable b0rked setup]

* Thijs Kinkhorst <[EMAIL PROTECTED]> [2006-01-18 10:26]:
> Mr Zimmerman's reference to Kennedy is an excellent example of such a
> metaphorical construct. When Kennedy said that, there will undoubtedly
> have been people who uttered "Hey, he's not German! He's lying!". But
> luckily most people will have understood what he meant.

 Then it's still Kennedy's problem, because he didn't claim something
for others.

 I know what you mean, though Mark is forcing a claim onto us, where the
term Debian Developer is quite strictly defined within our roles, people
in the NM queue aren't called Debian Developers.

 For me and quite some others, if you read the thread, the term $foo
Developer implies that the person is able to incorporate changes into
$foo directly. I understand what Mark meant, but on the wiki page where
the cite is there isn't any context at all, and no explenation on how
it's meant. It's vastly misunderstandable.

> Same goes for Shuttleworth here, if it wasn't obvious from the context
> already (which IMO it was)

 The thing is, there isn't any context in that wiki page. I'm pleased
that he sees us as (in)valueable, but given that still every now and
then misguided reports appear doesn't really help, especially when it's
about ubuntu changed packages which we can't do anything about.

 So long,
Alfie
-- 
use Mail::Signature;
$sig = Mail::Signature->new;
print $sig->random;


signature.asc
Description: Digital signature

Re: New cyrus-sasl2 packages

[Gerfried Fuchs]

* "Roberto C. Sanchez" <[EMAIL PROTECTED]> [2006-10-16 01:18]:
> Mail-Followup-To: ...

 quite helfpul, if you ask me. :)  I'm not sure if you wanted that, but
I'm following your wish.

> * These packages are still in a state of flux, so please bear with us

 And they are, as one can see in #393318 - the bug isn't in libetpan nor
in etpan-ng.  Please keep in mind that filing FTBFS RC bugs because of
some package that is "still in a state of flux" is helping at no end ...
Especially FTBFS bugs which don't appear in a clean unstable chroot
aren't helpful at all.  If you still work on the package and don't
upload it, there is no problem - and you still can fix the problems
appearing within your own package.

 So long,
Alfie
-- 
"This is Linux Country. On a quiet night, you can hear Windows reboot."
  -- .sig in <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: libdb transition policy?

[Gerfried Fuchs]

Hi!

 Sorry for late response.

* "Nikita V. Youshchenko" <[EMAIL PROTECTED]> [2006-05-24 12:10]:
>> However, contrary to what the NM templates suggest, symbol versioning
>> is not a cure-all for all ABI incompatibilities.  If libetpan returns
>> a DB_ENV * in its API, you need to port[1] all its dependencies to the
>> new Berkeley DB version.
> 
> No, libetpan uses libdb only internally, and does not export it.
> 
> So I guess the question is to people who maintain etpan-ng and 
> sylpheed-claws-gtk2 - is it safe for your packages if I will upload new 
> version of libetpan (without soname change or package name change) that 
> will link against libdb4.4?

 I don't know if anyone has tried to, but I spoke to Hoa (= upstream)
about the thing, and it was like I expected: libetpan uses libdb for its
cache files. If it can't read them (like, b0rked file, or incompatible
old db file) it would get regenerated anyway. So there is no
compatibility problem with changing the libdb in libetpan at all.

 Have fun with updating the library, it won't affect depending packages. :)
Some times are that easy to solve, you know?

 So long,
Alfie
-- 
So ist das Leben eben: Es muss Beben geben, ab und zu.
Noch eben standst Du in der Sonne -- uuh, da kommt der Regen
  -- Seeed, "Tide Is High"


signature.asc
Description: Digital signature

Bug#373416: ITP: tworld -- Chip's Challenge Game Engine Emulation

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: tworld
  Version : 1.3.0
  Upstream Author : Brian Raiter <[EMAIL PROTECTED]>
* URL : http://www.muppetlabs.com/~breadbox/software/tworld/
* License : GPL
  Programming Lang: C
  Description : Chip's Challenge Game Engine Emulation

 Tile World is an emulation of the game "Chip's Challenge".  "Chip's
 Challenge" was originally written for the Atari Lynx by Chuck Sommerville,
 and was later ported to MS Windows by Microsoft (among other ports).
 .
 Please note: Tile World is an emulation of the game engine(s) only.  It does
 not come with the chips.dat file that contains the original level set.  This
 file is copyrighted and cannot be freely distributed.  The chips.dat file
 was originally part of the MS version of "Chip's Challenge".  If you have a
 copy of this version of the game, you can use that file to play the game in
 Tile World.  If you do not have a copy of this file, however, you can still
 play Tile World with the many freely available level sets created by fans of
 the original game, including CCLP2.  Because the version that Microsoft
 released introduced a number of changes to the rules of the game, Tile World
 is capable of emulating either the MS version or the original Atari Lynx
 version of the game.

 There is an intro.dat with 9 levels included that are free, so it can
go into main.  I am though taking a closer look into the CCLP2 (Chip's
Challenge Level Pack #2) for further DFSG free levels for the engine.
If I don't find any I hope there are at least some of them able to go
into non-free.

 So long,
Rhonda
-- 
Jetzt ist Sommer, egal ob man schwitzt oder friert,
Sommer ist, was in deinem Kopf passiert.
Es ist Sommer, ich hab das klar gemacht:
Sommer ist, wenn man trotzdem lacht.   -- Wise Guys, "Es ist Sommer"


signature.asc
Description: Digital signature

dpkg-reconfigure and postinst

[Gerfried Fuchs]

Hi!

 I am having a problem, and I guess I might not be the only one who
might stumble into it.  When one wants to do something in new installs
of the package, they usually check for $2 != "" in the postinst and put
the stuff in there.  So far, so good, and policy friendly because you
might not create ill side effects about user expectations to no changes
during upgrades.

 When though the stuff in between that condition is also guided by some
debconf questions, people might want to have it also being run on a
dpkg-reconfigure.  That makes it somewhat tricky, because from what I
see the postinst is called just the same way like a reinstall of the
very same package version, that is, with the version number prior
installed in $2.

 Left aside that I don't see a real chance currently to differentiate
between a dpkg-reconfigure and a reinstall of the same version, it still
leaves me with the problem that I would need to dynamically generate the
postinst on package build to contain the exact version of the package I
am building.

 Is my analysis flawed?  Is there a way to differentiate between a
reconfigure and a reinstall that I didn't see?  Is there a cleaner
approach to this problem than dynamically generating the postinst?

 Thank in advance for your thoughts, and a Cc might be nice, though I'm
checking with the list archives.

 So long,
Alfie
-- 
   char *strstr(const char *haystack, const char *needle);
  -- STRSTR(3)  Linux Programmer's Manual


signature.asc
Description: Digital signature

Re: I propose gazillion packages (LONG)

[Gerfried Fuchs]

On 17 Aug 2000, Juhapekka Tolvanen <[EMAIL PROTECTED]> wrote:
> http://www.cpt.univ-mrs.fr/~penne/Zsid/
> 
> Yes, we have that xsidplay, but it uses qt-libraries, and therefore it is
> not in main-directory. Zsid is under GNU GPL. I would actually use this
> program.

 I think this is a good idea.  Thanks for the pointer, I might do an ITP
on this in the next time...   Let's see how it turns out (actually I'm a
bit stressed at my work).

 Get back to me on this topic in some weeks time, if you don't hear
anything.

> Gnome-db:
> 
> http://www.gnome.org/gnome-db/
> 
> Needed by gASQL.

 Already packed. It's package-names are a bit strange to me, though:

[EMAIL PROTECTED]:~ > grep-available -FSource -sPackage gnome-db
Package: libgda-dev
Package: libgda0

 Have fun!
Alfie
-- 
(1) Everything depends.
(2) Nothing is always.
(3) Everything is sometimes.

libgd1 vs. libgd1g

[Gerfried Fuchs]

Hi!

 I've noticed a serious problem with libgd1 (or, libgd1g) during the
last month. And I don't really know what to do about.

 webalizer and linuxconf now depends on libgd1g, which currently isn't
anymore available from our ftp-servers.  And on the other hand
libgd-perl depends on libgd1, which seems to be a more recent version of
libgd1g (I think both provide the same thing?)

 libgd1 conflicts with libgd1g...  So, what is to be done, where is the
problem here?  Should libgd-perl be recompiled against libgd1g, which
seems to be an older version and not available on the servers; or should
be webalizer and linuxconf be recompiled against libgd1 (which they were
about a month ago or so, IIRC).

 So, my main question is - why those 2 packages? And furthermore,
against which packages should I file bugreports to solve this (if it's
really needed and the DM of those packages don't read this)?

 Thanks for any hints!
Alfie
-- 
I predict that today will be remembered until tomorrow!


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

Re: libgd1 vs. libgd1g

[Gerfried Fuchs]

Please refrain from Cc:ing me - I _do_ read the lists I'm posting to
*sigh*  It seems that that can't be said often enough.

On 04 Sep 2000, Stefan Gybas <[EMAIL PROTECTED]> wrote:
> The libgd maintainer decided to drop support for a libc5-based libgd and
> renamed the libgd1g package to libgd1 (I personally don't think that this
> was a good idea as it might cause problems during upgrades).

 Do I interpret this right that I should file a bugreport for recompile
against webalizer, then?

 Thanks for the help.
Alfie
-- 
You've been leading a dog's life.  Stay off the furniture.


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

Re: X and runlevels

[Gerfried Fuchs]

On 04 Sep 2000, Ethan Benson <[EMAIL PROTECTED]> wrote:
> also debian believes in leaving the runlevel configuration to the
> admin to define.

 Sure - but there is the FHS (I hope that I read it there) that defines
what at least runlevel 2 and 3 are for.  I would really like to see that
Debian complies with the FHS in that case, when it complies to it in the
other meanings also, quite strict, even.

 Just a thought...
Alfie
-- 
Today is the tomorrow you worried about yesterday


pgp0SgW8Mx9vM.pgp
Description: PGP signature

Re: X and runlevels

[Gerfried Fuchs]

On 04 Sep 2000, Brian Mays <[EMAIL PROTECTED]> wrote:
> Not quite.  The FHS briefly mentions *System V's* runlevel 2 and 3
> (along with Berkley's multiuser state).  It does not specify anything
> about runlevels for Linux or any other OS.

 O.k., you're right - it was on linuxbase.org. Which we support,
according to their main-page. And there is this linked from there:


.- quote -
| --- start of cut text --
| 0   halt
| 1   single user mode
| 2   multiuser with no remote networking
| 3   normal/full multiuser
| 4   reserved for local use, default is normal/full multiuser
| 5   xdm or equivalent
| 6   reboot
| --- end 
`- quote -

 So, I'm asking, why we don't follow this guidelines?  I don't see any
contradiction with our current approach to leave it up to the user. That
won't interfer IMHO, for the update-rc script (or what ever it's called)
doesn't touch the links if any of them exists, right?  So the user can
still change 'em to her/his likes.

 Now, are we part of the linuxbase-project or aren't we?  I know that
it's not good to take everything without asking it - but the current
setup is somewhat nonsense to me - 4 runlevels with the same setup

 Just a thought.
Alfie
-- 
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstände
(Mausbewegung) und "ga" sagen (Mausklick) abzukommen, zugunsten eines
mächtigeren und langwierig zu erlernenden Tools (Sprache).
   -- Achim Linder in de.comp.os.linux.misc


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

alternatives for MUA and NUA?

[Gerfried Fuchs]

Hi!

 Today I stumbled across my .muttrc and found that I've hardcoded the
pager (w3m ;) and the editor (vim :) into it. On the other hand I find
the alternatives-mechanismus really useful so I changed it to pager and
editor which works really fine.

 Now there doesn't seem to be an alternative for the MUAs or the NUAs.
I'd really like to have that in there so that packages like pinfo or
muttzilla (just for an example) could work "out of the box" without
needing to twitch with the configuration files.  I think that would be a
good thing, don't you think so?

 And, on the other hand, if you have any packages that are using hard
coded pagers, editors or so into it's rc files waste a thought about
changing it to the alternatives name ``pager'' and ``editor''.  I really
think that this should be a little more used so the people know about it
and also use it...

 Just a thought.
Alfie
-- 
If A equals success, then the formula is A = X + Y + Z.  X is work.  Y
is play.  Z is keep your mouth shut.
-- Albert Einstein


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

Re: alternatives for MUA and NUA?

[Gerfried Fuchs]

On 05 Sep 2000, Andreas Fuchs <[EMAIL PROTECTED]> wrote:
> 
> Today, Hamish Moffatt <[EMAIL PROTECTED]> wrote:
> > Do most mail readers have the same command line interface? Perhaps,
> > but I really doubt that news readers do.

*scratches*  Uhm, right, I haven't thought about that *damnit*  It
sounded so good when it came to my mind, though...

 On the other hand - I haven't received either mine or Hamish's Mail on
that topic yet, just Andreas' response?  Uhm, I wonder what else I might
have missed?

 So long!
Alfie
-- 
Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstände
(Mausbewegung) und "ga" sagen (Mausklick) abzukommen, zugunsten eines
mächtigeren und langwierig zu erlernenden Tools (Sprache).
   -- Achim Linder in de.comp.os.linux.misc


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

Reopened: numbers with ' (for cellspreading) can't be calculated with

[Gerfried Fuchs]

reopen 70870
# On 05 Sep 2000, Debian Bug Tracking System <[EMAIL PROTECTED]> wrote:
# > Subject: Fixed in CVS
# > 
# > This has been fixed in the development tree.
# > The patch will be in the next release.
#
# ... then please close it with the next release - the bug is still in
# the packages on our ftp-site, isn't it.
#
# You closed it the second time - the bug is _not_ to be closed when it
# is not uploaded yet, right?  I don't know if Severity: fixed is for
# that?  But closing the bug is not the right thing to do, IMHO. Correct
# me, if you like
#
# I sent this also do -devel, to maybe clearify that a little bit.
#
#  So long!
# Alfie
-- 
You've been leading a dog's life.  Stay off the furniture.


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

jabber field on db.debian.org?

[Gerfried Fuchs]

Hi!

 I was just wondering - there is this icq-field on
, which I have to say I'm not really happy with.
It's not the kind of thing that seems the right thing[tm] for Debian. I
would rather like to have a jabber field instead of that

 jabber, you might ask?  From the jabber.org FAQ: "Jabber is an
XML-based, open-source system and protocol for real-time messaging and
presence notification."  You might say: "Hey, that's the same as icq, so
why bother?"  But I say: "Hey, it's open-source, and that's what Debian
is all about, right?"  So, instead of supporting (and even encouraging
the developers!) the usage of a closed-source (but reverse engineered?)
protocol we should state once again what Debian is all about, right?

 I see that there might be problems due to the translation: Current
icq-field can't simply be turned into a jabber-field which would produce
some problems. On the other hand, another field might take lots of space
on the disk.

 So I thought a little about it and came up with the following:

-) The current field could be used for either one, and on display it
could be decided that it is a icq-field if it contains only of numbers.

-) Or, during a short period (say, 2 months or so?) both fields could be
there, and icq should really be dropped.

-) Finally, icq field could simply be dropped.

 Last point isn't really the best way to go - though there are currently
only 115 people using the icq field, according to Jason Gunthorpe,
including me.  And I think I'm not the only one of those people (at
least I know also that Othmar Pasteka would encourage this change).

 Jason said he won't decide - I really understand that.  But maybe if
some of the other 113 people that are currently using the icq field (or
also others, that might use the jabber field) could comment on this it
would be greatly encouraged to express your feelings :-)

 So, comments are welcome, Cc: from messages to the list NOT!
Alfie

Bug#190302: Misusage of changelog!

[Gerfried Fuchs]

reopen 190302
thanks

Hi!

imagemagick (4:5.5.7.3-1) unstable; urgency=low
  
  * New upstream version.
  * Upstream fix: closes: #194306, #129990, #161422, #186610
  * This is not ImageMagick bug. : closes: #190302
 
 -- Ryuichi Arafune <[EMAIL PROTECTED]>  Fri, 23 May 2003 20:44:23 +0900

 You are plainly misusing your changelog for closing #190302. This has
*nothing* to do in the changelog, there are no *changes* in this upload
that address this. Rather send a mail to [EMAIL PROTECTED] explaining why
you close them.

 Btw., your line for "Upstream fix: closes:" is not very helpful for the
bug submitters neither. They'd have to check their records to see what
this bug really was. Please add informations on what was fixed so it can
be seen offline, too.

 Have fun,
Alfie
-- 
"'oder?' heisst wohl, dass Sie es nicht so genau wissen.
 Vielleicht sollten Sie sich erst einmal kundig machen."
  -- unknown XxXX-Employee


pgpWwM7J5lSSH.pgp
Description: PGP signature

Re: security in testing

[Gerfried Fuchs]

* Sven Luther <[EMAIL PROTECTED]> [2003-05-16 13:33]:
>   Such a package should be as close to possible to the version actually
>   in testing, and not depend on packages and/or versions that are not
>   yet in testing.

 So, you request more or less that every developer should backport fixes
themself from the usual new upstream version that fixes the problem (and
mostly always have new features too) to the version in testing, which
might even be older than just one upstream release, due to usual holdups
in the transition. It sounds like you like to have every developer be
able to do what the security team does. That requires much skill -- much
more than most of us possess!

 I for my part don't think that I could spend enough efforts in doing
this correct, and I don't think that I'm that far below average in
skills of the usual debian developer.

 What _is_ needed to do it correct to make it work is having people that
are *willing* to do such backport fixes -- and still people only keep
repeating that it is needed and needed, but still noone is stepping
forward to do the actual work. I for my part would be pleased to be of
help when it's needed, but I'm afraid that I lack of skill to be in the
core team (hell, I'm JAPH, with some C knowledge, but when it comes to
python, C++, java or whatever I'm out of luck), left aside the time
constraints I'm currently facing.

> Also, we could add 2 things, first the RM assitants, which are debian
> developers who have voluntereed to help the RM in this, and have the
> right to give the green light to uploads.

 Off topic: I haven't seen it on d-d-a, are they decided yet? Just
curious.

> Second, what could be done about NMUs. Maybe a small group of apprentice
> security team members could scan the security announcements, and prepare
> NMU of such security holed packages, in close contact with the
> maintainer and the RM or his assistants, or maybe even the security
> team, especially if the problems are also present in stable packages.

 This is nothing new and was said over and over again -- just that noone
yet seem to have raised interest to do the work! Sorry for my pessimism
but I doubt that this thread will really make anyone step forward this
time  I'd love to be told otherwise!

> So, with such an announcement, everyone wins

 Noone wins if noone likes to do the work, like I said before in this
thread. It would just make us look even more awkward, I guess.

> the maintainer will be able to fix things in testing more easily

 I've I understand you correct it wouldn't be easy, for backporting
fixes seldom is easy.

 So long!
Alfie
-- 
 I have  a little problem with a bug-report I received... *scratch*
 Alfie: I send those to /dev/null
  -- #debian-devel


pgp0KALJpZWCE.pgp
Description: PGP signature

Re: Bug#190302: Misusage of changelog!

[Gerfried Fuchs]

* Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> [2003-05-26 13:12]:
> Submitter receive a mail from bts which include the message that opened the
> bug: what should he hunt for exactly?

 Not only does the mail from bts _not_ include the message (like you
were told by others already), also other people reading the changelog
might be interested in it. I for my part am. Is it really asked for too
much to write _what_ is fixed? I rather thought this must be common
sense

 So long!
Alfie
-- 
ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware...
  -- _DeadBull_ in #debian.de


pgp1I18Nks3HM.pgp
Description: PGP signature

Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interface to MIME encoding and decoding

[Gerfried Fuchs]

* Kai Henningsen <[EMAIL PROTECTED]> [2003-05-24 15:10]:
> * Package name: libemail-mime-encodings-perl
>   Version : 1.0
>   Upstream Author : [EMAIL PROTECTED]
> * URL : 
> http://search.cpan.org/CPAN/authors/id/S/SI/SIMON/Email-MIME-Encodings-1.0.tar.gz
> * License : Same as Perl.
>   Description : A unified interface to MIME encoding and decoding

 Could you *kindly* add a long-description for the package, too? (for
your other ITPs, too).  Additional informations on what makes it more
useful/better than libmailtools-perl in this special case wouldn't be
wrong neither.

 Please, don't simply massfile ITPs without thinking on their impact and
without any deeper informations  Are you ITPing them because you
need them for another package that depends on all of them? Do you think
they will be used? What makes them good to have in the pool?

 So long!
Alfie
-- 
Linux. Auf die Verpackung kommt's nicht an!
  -- 


pgpIdAttfeBDG.pgp
Description: PGP signature

Re: Menu's 24 color policy

[Gerfried Fuchs]

* Gustavo Noronha Silva <[EMAIL PROTECTED]> [2003-05-24 05:48]:
> Does this mean that the, IMHO brain-dead, 24-color limit has
> been droped?
> 
>>From menu's changelog:
> 
>>   * No more require icons to use the colors from cmap.xpm.
>> Closes:#193231, #175430, #192218, #97080
>>   * No more install cmap.xpm. Closes:#172092

 If you take a look at /usr/share/doc/menu/menu.txt.gz Section 3.4. it
seems like that part was removed, yes.  It was formerly point 3. in the
list in that section (at least it is in the menu.txt.gz included in
woody).

 HTH & HAND!
Alf*cool :)*ie
-- 
#include 


pgpQsllx365do.pgp
Description: PGP signature

Re: Debian menu system update

[Gerfried Fuchs]

* Bill Allombert <[EMAIL PROTECTED]> [2003-05-28 15:26]:
>  - Icons are no more required to use 24 colors in cmap.xpm. See
> 
>  for explanations.

 I fail to see what this thread about "maybe say that programs that
output HTML etc. should output valid HTML etc." has to do with the 24
colors of the cmap.xpm?

 Can you please be a little bit more verbose, or send the correct link?

>  - Title entry must be unique amongst menu entries. Providing two menu
>entries with the same title is a bug.

 Is this checked somehow? Like the "failed to overwrite file foo which
is also in package bar" message from conflicting filenames on package
install?

 Thanks,
Alfie
-- 
Not that I have anything much against redundancy.  But I said that already.
 -- Larry Wall in <[EMAIL PROTECTED]>


pgpdPxNoaORO1.pgp
Description: PGP signature

Re: Bug#194550: ITP: libemail-mime-encodings-perl -- A unified interfa

[Gerfried Fuchs]

* Kai Henningsen <[EMAIL PROTECTED]> [2003-05-26 20:30]:
> [EMAIL PROTECTED] (Gerfried Fuchs)  wrote on 26.05.03 in <[EMAIL PROTECTED]>:
>>  Please, don't simply massfile ITPs without thinking on their impact and
>> without any deeper informations
> 
> Please don't assume someone jasn't thought about something just because  
> you haven't been personally informed about every detail.

 I am not quite sure why you think that you should inform me personally.
Though still my question holds, that you seem to have ignored. Recite:

| your other ITPs, too).  Additional informations on what makes it more
| useful/better than libmailtools-perl in this special case wouldn't be
| wrong neither.

 So, let me ask again: What makes it better/more useful than
libmailtools-perl?

 See, it is nothing personal (you seem to take it that way), but
packages with similar functionality should be questioned, and if the
intended things can be done with either one there is no big need to
duplicate the work and increase the pool with it.

> As for the long descriptions, I really don't see what the use is in an  
> ITP. The packages will of course have them.

 A long description in an ITP would
a) reduce the amount of questions why this package should be in the
 pool,
b) can get you suggestions for improvement of it before the package hits
 the pool, and
c) doesn't let you seem strange by ignoring a template that requests it.

 If you like to question c) feel free to discuss it, like e.g. with the
reportbug maintainers (they have valid reasons to include it, see a) and
b), I guess), but don't go and simply ignore it.

 So long!
Alfie
-- 
Aber, der Aufwand, Linux zu installieren und vim zu lernen ist *IMMER*
geringer, als Outlook das Schreiben von vernünftigen Mails beizubringen. ;)
  -- Jens Benecke


pgpb1qznsg7pC.pgp
Description: PGP signature

Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

Hi!

 Yes, I've read the testing page with the FAQ and both the
testing_excuses and testing_output, but I can't see the reason why
libsidplay doesn't enter testing.

 The following packages depend on it: xmms-sid, mp3blaster, xsidplay,
sidplay-base (from the same source) and gst-plugins.  Only the latest
isn't a valid candidate but that must not hold it back because it has
never been in testing anyway.

 From the update_output it seems that alpha seems to have problems with
the package -- but shouldn't then at least one of the packages depending
on it be outdated for alpha and thus being no valid candidate?

 It would be nice if someone can unpuzzle me here  Thanks.
Alfie
-- 
SILVER SERVER  \\ \\ \
[EMAIL PROTECTED]www.sil.at
 
   keep your backbone tidy

Re: Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

On Thu, Jul 03, 2003 at 12:50:50PM +0200, Björn Stenberg wrote:
> Gerfried Fuchs wrote:
>>  Yes, I've read the testing page with the FAQ and both the
>> testing_excuses and testing_output, but I can't see the reason why
>> libsidplay doesn't enter testing.
> 
> I've written a little script that tries to answer precisely this type of
> question. You can run it here: http://bjorn.haxx.se/debian/

 Thanks for the great script.  It shows me that the testing script seems
 to be buggy, because:

>   - Updating sidplay-base makes 1 packages uninstallable on alpha: 
> sidplay-base

 Uhm, that is somehow nonsense. How can an update of a package make
itself uninstallable? What's the reasoning behind it?

>   - Updating xmms-sid makes 1 packages uninstallable on alpha: xmms-sid
>   - Updating xsidplay makes 1 packages uninstallable on alpha: xsidplay
> 
> The packages are waiting for each other, so none of them can go in. It looks
> like a nudge by a maintainer is required.

 From the texting I would interpret this as they are waiting for
_themselfes_, not for the others.

 What nudge by a maintainer are you talking about? Especially, which
maintainer (testing-maintainer?)

> Platforms are tested in alphabetical order, and only the first that
> breaks is displayed.

 Thanks, that explains a lot.  But it still doesn't explain why the
package holds back itself...  Is this a bug in the testing script? From
what I understand the testing script should be able to see such circular
dependencies -- but a dependency that breaks itself seems to be weird.

 Have fun,
Alfie
-- 
SILVER SERVER  \\ \\ \
[EMAIL PROTECTED]www.sil.at
 
   keep your backbone tidy

Re: Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

On Thu, Jul 03, 2003 at 06:03:38PM +0200, Björn Stenberg wrote:
> Gerfried Fuchs wrote:
>>  Uhm, that is somehow nonsense. How can an update of a package make
>> itself uninstallable? What's the reasoning behind it?
> 
> Because it breaks testing rule #5: "The operation of installing the
> package into "testing" must not break any packages currently in
> "testing".

 Please read the output again. It claims that the install of
sidplay-base would render sidplay-base (e.g. _itself_) broken -- that is
what I call nonsense for the broken rendered sidplay-base would be
replaced, that's what it's all about.  A package should never be able to
render _itself_ broken.

> Updating sidplay-base alone breaks the current versions of xmms-sid
> and xsidplay. This is not allowed, and thus sidplay-base is
> uninstallable.

 Please read the documentation for the testing script again -- that
should already be triggered by the script. Read the part in the FAQ
about the "real, non-trivial example". This is exactly that the example
describes and what it claims to be able to do already.

> The solution is to update all of the packages at once, which requires
> manual intervention.

 I don't see why it would need manual intervention. Either the
documentation is ahead of the script or it is wrong. It is claimed in
the documentation for quite some time that this is handled automagically
already and this is the whole purpose for why the packages are
repeatedly mentioned in the update_output.

 So simply put: You don't know neither why they don't move to testing
automatically like they should (and I'm quite sure that it already
worked that way...). I still think that there must be a different
problem here, or rather someone b0rked the script. I don't want to
accuse anyone to have done it, I don't need anyone responsible for the
brokeness, but I'm not sure if it's really b0rked or if there is
something that I misunderstood

 So long,
Alfie
-- 
SILVER SERVER  \\ \\ \
[EMAIL PROTECTED]www.sil.at
 
   keep your backbone tidy

Re: Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

On Thu, Jul 03, 2003 at 01:49:28PM -0400, Anthony DeRobertis wrote:
> On Thursday, Jul 3, 2003, at 07:21 US/Eastern, Gerfried Fuchs wrote:
>> Uhm, that is somehow nonsense. How can an update of a package make
>>itself uninstallable? What's the reasoning behind it?
> 
> Easily. Example:
> 
>   Package: foo
>   Version: 1.0.6-4
>   Depends: libc6 >= 2.2.0
> 
> vs.
> 
>   Package: foo
>   Version: 1.0.7-1
>   Depends: libc6 >= 2.4.0
> 
> Replacing foo-1.0.6-4 with 1.0.7-1 would make foo uninstallable 
> (becasue there is no glibc-2.4.0 in testing)

 Please check the update_excuses, it would make package foo _not_ a
valid candidate, if that happens.

>> Thanks, that explains a lot.  But it still doesn't explain why the
>>package holds back itself...  Is this a bug in the testing script?
> 
> No.

 What makes you so sure? If it is just a circular dependency problem
like Björn said it should be caught already, like documented (and worked
before). I never noticed before that a package seems to hold back
itself though.

 So long,
Alfie
-- 
SILVER SERVER  \\ \\ \
[EMAIL PROTECTED]www.sil.at
 
   keep your backbone tidy

Re: Why doesn't libsidplay enter testing?

[Gerfried Fuchs]

* Colin Watson <[EMAIL PROTECTED]> [2003-07-04 00:03]:
> On Thu, Jul 03, 2003 at 07:58:37PM +0200, Gerfried Fuchs wrote:
>>  Please check the update_excuses, it would make package foo _not_ a
>> valid candidate, if that happens.
> 
> That doesn't happen for circular dependencies (i.e. cycles of packages
> that each depend on newer versions of each other than are in testing),
> the reason being that if they weren't considered valid candidates then
> such cycles could never get into testing at all. (Invalid candidates are
> completely ignored - they aren't eligible for hinting, even.)

 Oh, didn't know that part yet, thanks for the enlightenment.

> Please stop saying rude things like "Please check " to the people
> who are trying to explain the state of play to you, because they are
> right: it has been like this for a long time.

 Sorry, I don't get it why you call it rude. It might be just me but I
would have considered it rude if I told Anthony to "RTF update_excuses".
If you take what I wrote as rude then sorry, I didn't mean it that way.
I even haven't thought that anyone would take a "please check" as rude
anyway, and I still don't understand it why you might think so  And
like Anthony's answer showed he hasn't taken it as rude neither, and
even he thought it would happen to be written out in update_excuses.

>   Upgrading either the foo source package alone or the libfoo source
>   package alone renders foo uninstallable. Upgrading both simultaneously
>   works. The latter requires manual action (or the occasional bit of
>   guesswork by the testing scripts). It has always been this way.

 Yes, it has always been this way. Or rather not, for I don't see the
need for manual action, it is documented that these cases are cought by
the testing script since ages, and it worked without manual action for
quite some time already (from what I can tell).

 I just like to know if there is really the need for manual action for
such things every now and then (then this should be noted in the
documentation and I consider it rather as a bug, for there is not much
magic in this case, IMHO) or if there is something else behind this very
case, which I don't grok yet.

 So long,
Alfie [no, not meant rude; don't understand it as rude]

debconf 2005 in Vienna, Austria

[Gerfried Fuchs]

Hi!

I'd like to start organizing the debconf for the year 2005 in Vienna,
Austria.  Why that early announce?  So we have time enough to find
sponsors, get the location fixed and find the time to raise the money
needed for the travels and such.  And 2005 because this years debconf
has been in europe and 2004 should be on a different continent (Asia,
America, Australia -- there are many nice places that start with A :-)

 Why Vienna, Austria?  Because it is a quite central place in europe,
it isn't that expensive like Oslo, and I also want to be able to visit
a debconf myself, of course ,-)

 Yes, I know, oranizing isn't only fun but mainly much much work. I have
already discussed with some people that are willing to help me there, on
which I can count.

 If you think it is a really bad idea please step forward and _explain_.
A simple "I don't like it there" will be simply ignored if there are no
reasons attached to it.

 Of course the date hasn't been decided yet, but I guess it will be
around the same time like the last two: in july, with no conflict with
other important events.

 So long, and thanks for the attention.
Alfie [prepared to be called a dreamer/moron/whatever]
P.S.: It would be more than helpful if someone can write a report about
   this years debconf for the events page that we can take a look at to
   see how to make it right ,)
-- 
use Mail::Signature;
$sig = Mail::Signature->new;
print $sig->random;


pgpXWPmRFzV7n.pgp
Description: PGP signature

Re: debconf 2005 in Vienna, Austria

[Gerfried Fuchs]

* Christian Perrier <[EMAIL PROTECTED]> [2003-07-29 17:37]:
> Quoting Sebastian D.B. Krause ([EMAIL PROTECTED]):
>> > July in Vienna!  More power to you!
>> 
>> Well, but then try not to be on the same date as LinuxTag 2005. :)

 If you would have read the paragraph that was quoted you would have
seen that a conflict with other events (like LinuxTag) is a no way :)

> But close to it would be a good idea also. Dunno whether LinuxTag
> happens on a week-end or during the week, but it would be ideal to
> have Debconf one week after LinuxTag (so that people attending LT
> could come at DebCamp in the between).

 Yes, that's what I thought about initially, too.  Joey?  When does
LT 2k5 happen to be? ,)

> And, I definitely vote for Vienna. Wonderful city which I could easily
> convince wife and kids to plan a visit to...which could excuse a
> week-end geeking for myself just in the neighborhood.. :-)

 Which brings me to one point: My wife plans to do handling of children
during the stay.  She is about to start studying paedagogy and had one
test for her A-levels in paedagogy too, so I am quite confident that she
will do the right thing[tm].

> Another good argument for Vienna : being central in Europe, it is
> close to the most eastern countries of the continent...

 Yes, thats one major reason, too. So the travel for people from eastern
europe won't be too expensive and long.

> Gerfried, I guess you're crazy but this is a great idea.

 Of course I'm crazy :)   I wonder if that should be a check in the NM
process.

 So long,
ALfie
-- 
SILVER SERVER  \\ \\ \
[EMAIL PROTECTED]   www.sil.at
 
   keep your backbone tidy

someone interested in adopting grub-client?

[Gerfried Fuchs]

Hi!

 grub-client is a distributed webcrawler client written in c++. The
biggest problem with it is that it simply doesn't work, and I don't grok
why. I'm not that familar with c++ and multithreading and don't know
where to look for the bug. Furthermore it seems that on the search
engine front (for which the client crawls) there is no real progress so
I can't say where this project leads to.

 I am not sure if there are really people interested, so if noone likes
to pick it up I'll request the removal of the package from testing and
unstable. I don't see any sense in having the package in the pool when
there is no real interest in it, especially if it has a release critical
bugreport on it that I can't track down.

 Mail Cc'ed to the RC bugreporter, maybe he is interested to work on the
issue and adopt the package. Jim, if you like to do it I am willing to
sponsor you. The part about sponsoring this package holds for everyone
else too, btw.

 So long,
Alfie
-- 
  * *sigh* I finally upload a fixed get-foo-flags and the next day a new
upstream comes out.
  * oh, new upstream, btw.
 -- Marcelo E. Magallon, changelog.Debian for wmaker (0.64.0-1)


pgpu6eeugV6wG.pgp
Description: PGP signature

Bug#207624: ITP: tetrinet -- client and server for tetrinet, a networked tetris version

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist


* Package name: tetrinet
  Version : 0.10
  Upstream Author : Andrew Church <[EMAIL PROTECTED]>
* URL : http://achurch.org/tetrinet/
* License : Public Domain
  Description : client and server for tetrinet, a networked tetris version

Included in this package you will find tetrinet which is a ncurses
client and tetrinet-server which is the server program. Together you can
use them to play tetrinet with friends over the internet.

The client requires 48 lines at least, but you get only one chat line
during the game, then.

The server doesn't seem to accept any special options or have a
configuration file, just one room with specials enabled.

 Don't take this description too serious, it won't be the final one for
the package, just a quick shot about what's going on (but still better
than those single line long descriptions :-/ ).

 About the name of the package: Discussable, but I don't really know
what to use else. The package is simply called tetrinet upstream.

 Please Cc me on replies (or keep the bug address in the list) so I
don't miss any valueable informations, I scan debian-devel only through
the archive.

 So long,
Alfie
-- 
"Die Leude wolln dass was passiert,
 die Leude wolln dass Bass masiert,
 die Leude wolln das krass serviert:
 Die Leude wolln uns!"-- 5 Sterne Deluxe, "Die Leude"

Bug#207624: ITP: tetrinet -- client and server for tetrinet, a networked tetris version

[Gerfried Fuchs]

* Alex de Landgraaf <[EMAIL PROTECTED]> [2003-08-28 13:52]:
> Would like to note that tetrinetx and gtetrinet are already in Debian.
> Tetrinetx is the game server voor tetrinet, gtetrinet is the gtk
> tetrinet client.

 I'm fully aware of this.

> Maybe something like tetrinet-ncurses is in order?

 Considering it, yes.

> In any way, having two tetrinet servers would probably break something

 Would break what? Sorry, we have tons of other servers doubled, like
apache and roxen; exim, postfix and sendmail; inetd and xinetd; xdm,
wdm, gdm and kdm...  What shall be different in this very case? Please
be a little bit more verbose...

> (and is redundant),

 Like the above.  Please don't say that if you haven't compared the
posibilities of the different things, otherwise your statement is moo.
I must confess that I haven't checked the real abilities of
tetrinet-server in this package but from what I see currently is that it
is very limited.  On the other hand, it is included in the upstream
source so it would maybe distract the upstream author if he see that it
is not included in the binary package.

> so at least take a look at tetrinetx and contact its maintainer to
> sync things...

 Can you sync postfix with exim, please? Sorry, this sounds strange...
It is not a spin off of tetrinetx, that's the way things work in the
open source/free software community. Different people try their own
approach. Only time will tell which will stay and which will pass away.
I for myself don't like to judge these things and say: "let's kill this
off, it looks moo".

 Hell, you made me defend that little 16k piece of crap, well done :-)

 So long,
Alfie
-- 
 hat einer von euch schon bind9 installiert?
<_eis> das neue root kit? :->
  -- #debian.de


pgp8A30x8oLlz.pgp
Description: PGP signature

Bug#207624: ITP: tetrinet -- client and server for tetrinet, a networked tetris version

[Gerfried Fuchs]

* Josselin Mouette <[EMAIL PROTECTED]> [2003-08-28 13:06]:
> Le jeu 28/08/2003 à 12:35, Gerfried Fuchs a écrit :
>>  About the name of the package: Discussable, but I don't really know
>> what to use else. The package is simply called tetrinet upstream.
> 
> Why not split into tetrinet-server and tetrinet-client?

 The server binary has only 16k compared to 61k client binary, and I
dislike the idea of the overhead for this small packages.  Beside that,
I don't think that I will provide an init.d script for it neither,
doesn't make much sense IMNSHO.

 I talked with fabbione a little bit about it, maybe I will leave out
the tetrinet-server binary completely, it doesn't offer anything fancy
anyway so people who like to have their own server running should rather
use tetrinetx.

 If I leave it out I might consider naming the package tetrinet-client
as a whole (for the binary -- I guess I'll stick with tetrinet for the
source package).

 I am wait for a reaction from upstream too currently. I will consider
his ideas on the topic, too.

 So long, and thanks for the input.
Alfie
-- 
"Kaum wird das Wetter schlechter und die Tage kürzer, fallen die
Newbies über das Netz her wie die Blätter von den Bäumen."
 (Ulf Schaefer in de.talk.jokes)


pgpFJLMwRKM7F.pgp
Description: PGP signature

Bug#320939: ITP: blosxom-plugins -- various plugins for the blosxom blog tool

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: blosxom-plugins
  Version : 0.5 (propably)
  Upstream Author : Various
* URL : http://www.blosxom.com/plugins/
* License : GPL, BSD, ...
  Description : various plugins for the blosxom blogging tool

 This package contains various helpful plugins for the blosxom blogging
 tool. They are meant to be a useful extension to the basic
 functionality. Included you also find a (de)activate script for easy
 maintenance.

 About the maintenance script I think of something along the a2ensite
and a2dissite scripts, together with some dpkg-reconfigure hooks, too.
The integration of the latter will mark version 1.0 for me. I'm open for
suggestions of plugins to integrate, I am thinking at least of the atom,
calendar, seemore, debtags and entries_cache.

 So long,
Alfie
-- 
Wieso gibt's kan sync Befehl fürs Hirn?  Wieso steh i jetzt?
 -- 2002-12-04, in der Arbeit aufgeschnappt


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

Re: mass bug filing on packages that are blocking use of cdebconf

[Gerfried Fuchs]

* Joey Hess <[EMAIL PROTECTED]> [2005-09-26 19:57]:
> Joey Hess wrote:
>> Just a reminder that these maintainers still have packages that depend
>> on debconf by itself without an alternate dependency on | debconf-2.0.
>> As I mentioned in my original post, I plan to file bugs on all of these
>> soon, which, omitting all the lg-issue* packages, comes to about 550
>> bugs.
> (Original post here:
> http://lists.debian.org/debian-devel/2005/08/msg00136.html)
> 
> This is your third and final reminder. I count 542 packages remaining,
> down only 9 from last month. I assume most of the people below do not
> read debian-devel, so I've taken the librerty of BCCing you all. :-P

 I wonder why you didn't sent it to debian-devel-announce then? This is
where this really belongs, not? This is what the list is for, not?

 So long,
Alfie [doing his updates]
P.S.: Yes, you are right. I ceaced to read debian-devel for quite a
  while due to the sheer mass of noise ratio. So Cc: me on replies
  that you think might be interesting to me, too. Honor the
  Mail-Followup-To: header.
-- 
 ZZcd ..
 oops
-- #jutesack


signature.asc
Description: Digital signature

Bug#478516: ITP: libcaptcha-recaptcha-perl -- perl implementation of the reCAPTCHA API

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: libcaptcha-recaptcha-perl
  Version : 0.92
  Upstream Author : Andy Armstrong <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/Captcha-reCAPTCHA/
* License : same as perl (GPL or Artistic License)
  Programming Lang: Perl
  Description : perl implementation of the reCAPTCHA API

 reCAPTCHA is a hybrid mechanical turk and captcha that allows visitors
 who complete the captcha to assist in the digitization of books.
 From http://recaptcha.net/learnmore.html:
 .
 reCAPTCHA improves the process of digitizing books by sending words that
 cannot be read by computers to the Web in the form of CAPTCHAs for
 humans to decipher. More specifically, each word that cannot be read
 correctly by OCR is placed on an image and used as a CAPTCHA. This is
 possible because most OCR programs alert you when a word cannot be read
 correctly.
 .
 To use reCAPTCHA you need to register your site here:
 https://admin.recaptcha.net/recaptcha/createsite/

 So long,
Rhonda



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

Re: Bug#550817: ITP: gitolite -- standalone, souped-up version of gitosis

[Gerfried Fuchs]

Hi!

* Stefano Zacchiroli  [2009-10-13 11:03:00 CEST]:
> What if one has no idea of what "gitosis" is? For such a person, the
> above description will be close to meaningless. I suggest expanding in a
> couple of words what gitosis is, turning the reference to it as
> something like "similar to gitosis".

 Let me repeat my response that I sent already to the bugreport:

|  Of course it isn't [the final version of the description]; it's just
| the short blurb that can be seen on the upstream website about it.
| Having a full fledged description at ITP stage means that one already
| started at working on the package - and given that an ITP is meant to
| be there so that we don't duplicate work and /personally/ the package
| description is something that I rather *not* think as first of when
| starting to work on a package sending out the ITP with something
| final package description is backwards, counter-productive and
| anachronistic to me. :)

 But for a quick roundup: gitosis is offering (key-based) ssh access
with ACLs to a git repository, including broken down to even branch
level based ACLs.

 So long! :)
Rhonda


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

Bug#550817: ITP: gitolite -- standalone, souped-up version of gitosis

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs 


* Package name: gitolite
  Version : 0.5
  Upstream Author : Sitaram Chamarty 
* URL : http://github.com/sitaramc/gitolite
* License : GPLv2
  Programming Lang: Perl
  Description : standalone, souped-up version of gitosis

Gitolite is a rewrite of gitosis, with a completely different config
file that allows (at last!) access control down to the branch level,
including specifying who can and cannot rewind a given branch.

 Thanks. :)
Rhonda



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

Re: Bug#550817: ITP: gitolite -- standalone, souped-up version of gitosis

[Gerfried Fuchs]

* Filippo Rusconi  [2009-10-13 12:06:29 CEST]:
> Well, I think that ITP bugs are *more* useful when the person reading
> the bug report can tell what the intended-to-be-packaged software
> does.

 There's always the upstream URL included that you can follow if you
think it's unclear anyway.

> Sometimes, when I go through ITP bug reports, I find myself thinking
> "Hmmm, that's interesting stuff, I'll have to check that from time to
> time"

 I consider it much more practical to go through the new packages in the
pools instead, for several reasons:

 -) you can already actually directly try the packages out instead of
having to crave for it to appear in the pool
 -) you can already actually write bugreports about bad package
descriptions (which I do regularly)
 -) you don't waste your time on ITPs that turns out to never appear in
the pool or die away upstream wise (which unfortunately does happen from
time to time)

 Of course, going through ITPs has its benefits too, but I guess
checking what's new in the pool might be more promising for your
approach and less waste of time because of "check that from time to
time". :)

 So long, and thanks anyway for your inputs!
Rhonda


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

Re: Bits from the FTPMaster meeting

[Gerfried Fuchs]

Hi!

 First of all, thanks for this great roundup. There are just some few
questions that popped up in my mind that I hope haven't asked yet
(wasn't able to check all the responses completely ...). Sorry if there
are duplications, a reference to the answer for easier tracking would be
appreciated, though. :)

* Joerg Jaspert  [2009-11-15 16:15:35 CET]:
> source-only uploads
> ---
> The current "winning" opinion is to go with the source+throw away
> binaries route.  We are close to being able to achieve this, it is
> simply that it has not yet been enabled.  Before any version of this
> can be enabled, buildd autosigning needs to be implemented in order
> that dak can differentiate buildd uploads vs maintainer uploads.

 I am a bit confused with respect to how buildd autosigning is required
for this. It makes it sound somehow like it would affect porter binary
uploads. Is this the case or am I reading too much into this? What's the
rationale for the requirement of autosiging needs, and would porters
still be able to upload binary-only without having them thrown away
because they aren't signed with a key in the buildd-keyring? It's
unfortunately not too uncommon that some buildds have issues over a
longer period of time, and being able to help while that's the case is
what I consider an important feature for a porter.

> Tracking arch all packages
> --
> #246992 asked us to not delete arch all packages before the
> corresponding (if any) arch any packages are available for all
> architectures.  Example: whenever a new source package for emacs23
> gets uploaded the installation of the metapackage emacs_*_all.deb
> breaks on most architectures until the needed Architecture: any
> packages like emacs23 get built by the buildds. That happens because
> dak removes all arch: all packages but the newest one.

 What exactly is meant with deleting here? From the pool? Or does it
mean that the Packages files will keep all versions of the arch all
packages in them and thus reducing the amount of uninstallable packages?
The later would be greatly help with regular reports of uninstallable
packages that weren't yet built and the old binary package depending on
the old arch package which otherwise wouldn't be available anymore. From
what I understand (and tried) apt does the right thing and chooses the
most recent versions in cases where it doesn't matter anyway.

 Thanks in advance for clearing up these questions, and again, thanks
for your work!

 So long,
Rhonda


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

Re: New source package formats now available

[Gerfried Fuchs]

Hi!

 Some few comments.

* Raphael Hertzog  [2009-11-21 16:54:36 CET]:
>  * even if you don't have any upstream patch right now, next time that
>someone must NMU your package, they can cleanly add a patch (with a
>proper DEP-3 header) without having to modify the build system

 This is nothing new for the 3.0 (quilt) format, this is a reason for
any patch system format, so this feels a bit like false-advertising,
sorry. Don't get me wrong, I use quilt where I have to touch upstream
sources myself and totally like it, I just don't see the need to use
this as advertising for the 3.0 format because that doesn't buy you much
more in that respect.

>  * in the long run it's best to standardize on a single patch system (new
>contributors need to learn a single system, more people can help you,
>etc.) and quilt appears to be that patch system.

 That part feels also a bit strange - I don't think it should be the
decision of the dpkg team to force people to use a specific patch
system. Again, I use quilt myself. Though, Debian (and free software in
general) always was about choice. And yes, I know, there's 3.0 (native),
but that wasn't mentioned.

> When you switch to "3.0 (quilt)", there are other changes that you might
> want to do:
>  * You can remove everything related to quilt in debian/rules
>(patch/unpatch logic, cleanup of quilt stamp file and its .pc
>directory).

 Unfortunately, I can't follow that "can remove". It sounds like it
would work if you keep it in. Unfortunately that's not the case. Please
take a look at the build logs for wesnoth 1:1.7.8-1. The story is easy:

 -) The buildd does a debian/rules clean.
 -) quilt doesn't find any applied patches (because dpkg doesn't create
the .pc/ directory structure)
 -) The buildd then starts with the building.
 -) quilt likes to apply the patches and failes because they already
*are* applied but quilt doesn't know about it.

 So pretty please, change that "can remove" into a "MUST remove",
otherwise you will stumble into problems.

> === Does a 3.0 (quilt) source package need to build-depend on quilt? ===
> 
> If you drop the quilt usage in debian/rules (patch/unpatch logic), then no.

 You *HAVE* to drop the quilt usage in debian/rules, otherwise it will
fail.

 So long, and thanks for the work involved, but this minor issues should
still be addressed, in one way or the other. :)

 *waves*
Rhonda


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

Re: New source package formats now available

[Gerfried Fuchs]

* Raphael Hertzog  [2009-11-21 20:51:51 CET]:
> Hi,
> 
> On Sat, 21 Nov 2009, Gerfried Fuchs wrote:
> > * Raphael Hertzog  [2009-11-21 16:54:36 CET]:
> > >  * even if you don't have any upstream patch right now, next time that
> > >someone must NMU your package, they can cleanly add a patch (with a
> > >proper DEP-3 header) without having to modify the build system
> > 
> >  This is nothing new for the 3.0 (quilt) format, this is a reason for
> > any patch system format, so this feels a bit like false-advertising,
> > sorry.
> 
> Currently a package without a patch system needs heavy modifications in
> debian/rules to setup the patch system. So when you want to add a patch in
> debian/patches and not in the .diff.gz, you have to choose a patch system
> in place of the maintainer.

 Heavy modification? What's so heavy on three entries there?

include /usr/share/quilt/quilt.make

clean:
[...]
unpatch

build-stamp: patch

 Sorry, but these additions are next to nowhere "heavy modifications",
that's a bit over overrating, to say the least.

> With 3.0 (quilt), you don't need to do any such modification... the patch
> system is already available even if not used. That's what this point
> means.

 The modifications are implied, but it means that the source format is
already this "heavy modification", on a similarly heavy modification
scale. Additionally, if someone wants to sepearte the patches into
feature-patches instead of one-modification-patch-per-upload they will
have to additionally pull in quilt anyway to work on it properly,
without having it implied through the build-depends and being guided in
the right direction through README.Source.

> In general it should work, but you're right that we have a problem
> here with the buildds running an old version of sbuild (there are still
> many buildd in that situation) because they do "dpkg-source -x" outside
> of the buildd chroot where quilt is not installed even if you added
> quilt in your build-depends.
> 
> AFAIK newer sbuild should do "dpkg-source -x" in the chroot where quilt is
> installed due to build-depends and the .pc directory is then created
> at unpack time.
> 
> >  -) quilt doesn't find any applied patches (because dpkg doesn't create
> > the .pc/ directory structure)
> 
> dpkg-source -x uses quilt if it's installed, so if it's here the .pc
> structure is created.

 Alright, thanks for explaining the issue - so for the time, what do you
suggest? Remove the quilt handling? Actually ignore the error that quilt
gives (like you suggested on IRC)? Or wait until the sbuild fix is
applied everywhere?

 Thanks,
Rhonda


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

Re: New source package formats now available

[Gerfried Fuchs]

Hi! :)

* Raphael Hertzog  [2009-11-22 10:48:14 CET]:
> > Note that the squeeze release goal only talks about 3.0 (quilt), not 3.0
> > (native), which kind of suggests 3.0 (quilt) is being forced down.
> > That's maybe not what you are thinking, but it's how it feels.
> 
> Well, the combination 3.0 (quilt) + 3.0 (native) offers the same range of
> choice as 1.0 alone in a more explicit manner. 3.0 (native) is for native
> packages and 3.0 (quilt) is for all the other who have an upstream tarball
> + a debian dir.

 Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
me).

 If you want to really make proper use of it (like seperating into
feature patches instead of one per upload) you need to have quilt
installed anyway, and speaking of NMUs, people that just download the
source, patch and upload will produce low-standard patches, most
probably not following the DEP3 because dpkg with 3.0 (quilt) doesn't
really offer what quilt offers. It feels a bit like the regression that
svn brought on top of cvs with taking away the posibility to tag
properly (but create tag-branches instead).

 3.0 (quilt) looks like a good idea, but it's still rough at the edges
somehow. :/  And about not needing a README.Source for it, I don't see
that because otherwise we wouldn't have the need for discussions like
that, especially if we want to have proper DEP3 tagged patches. :)

> > OTOH, "dpkg-source -x" should result in the same tree (including the .pc
> > directory), whatever the status of quilt installation is on the system.
> > Or if that is not possible without quilt, then dpkg-dev should depend on
> > quilt.
> 
> I don't agree with that statement. dpkg-source implements a subset of
> quilt to work without that tool installed, that subset defines the
> interface of the source package and it does not include the .pc directory
> in the general case. If you want that part which is internal to quilt
> itself, you just have to install quilt.

 It is causing troubles for people that are familiar with quilt and
think they will be able to work with quilt with the source package when
they dpkg-source -x it - which unfortunately isn't the case. Only when
quilt is installed, but then, this is getting different results
depending on the environment one has, and I thought this was always one
of the big NO-GOs in Debian that we should avoid - and here we have it
even intentional? Sorry that this doesn't make me (and from what I can
see others too) happy  :/

 About "you just have to install quilt" - *before* you unpack the
source. If you install it afterwards, you have lost.

 So long, and thanks. :)
Rhonda


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

Re: New source package formats now available

[Gerfried Fuchs]

* Goswin von Brederlow  [2009-11-23 09:48:36 CET]:
> Why do you think that? I can split patches any which way and edit the
> debian/patches/series to match all completly without quilt.

 How so? I don't find anything in man dpkg or dpkg-source that would
help with that.

> It only becomes simpler with quilt and you would always have it
> installed. A 3.0 (native) + quilt package would force people to use
> quilt and result in build failures for anyone missing the fact you use
> quilt manually instead of 3.0 (quilt) format. There really is no
> advantage in that.

 ?! What build failures? Can you please elaborate on why would you see
build failures down that path, anywhere?! There's the advantage in it
that people actually *do* have quilt installed to work properly with the
(implied) quilt patches instead of maybe having it not around and still
are expected to work on the patches.

> >  It is causing troubles for people that are familiar with quilt and
> > think they will be able to work with quilt with the source package when
> > they dpkg-source -x it - which unfortunately isn't the case. Only when
> > quilt is installed, but then, this is getting different results
> > depending on the environment one has, and I thought this was always one
> > of the big NO-GOs in Debian that we should avoid - and here we have it
> > even intentional? Sorry that this doesn't make me (and from what I can
> > see others too) happy  :/
> 
> And as a quilt using person you often have quilt not installed?

 This isn't about me or you but about NMUing people or others you want
to have working on the package. And the question is trying to distract
from the issue and not answering the question, sorry.

> Worst case you unpack the source again after installing quilt. So far
> this only happened to me once. Since then I have quilt installed per
> default in new chroots ment for compiling.

 Worst case you don't know about it because it is said to not require a
README.Source anymore and is nowhere really hinted that it will give you
different results.

> >  About "you just have to install quilt" - *before* you unpack the
> > source. If you install it afterwards, you have lost.
> 
> So you do want a dpkg-source --quiltify-source to fix this post
> unpacking instead of manually unpacking the source again?

 I would expect a dpkg-source -x to always result in the same thing, no
matter wether quilt is installed or not. And when the format claims to
be (quilt) I expect it to be quilt-ready *by default*. Implementing just
a subset but calling that subset with the same name is just confusing. :/

 So long. :)
Rhonda


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

Re: New source package formats now available

[Gerfried Fuchs]

* Raphael Hertzog  [2009-11-23 09:50:15 CET]:
> On Mon, 23 Nov 2009, Gerfried Fuchs wrote:
> >  Actually, I feel rather to convert my packages to 3.0 (native) + quilt.
> > The way quilt is implied in 3.0 (quilt) doesn't seem to be helpful (to
> > me).
> 
> Yay for reuploading the full tarball for each revision! I'd rather you
> keep using 1.0 instead of doing this...

 But 1.0 won't give me orig.tar.bz2 support. And your plan is to kill
off 1.0 and implicit convert it to 3.0 (quilt) so "keep using 1.0" would
still mean having to change stuff in the package.

> The automatic patch now features DEP-3 headers by default. The NMUer can
> rename it and edit the headers easily. If he wants to create one patch
> per feature, he can simply rebuild the source package after having applied
> each patch.

 Have you tried rebuilding the source package after having applied a
patch in wesnoth? Or OpenOffice.org? Or nexuiz-data? Or fillets-ng-data?
:)

> For each patch:
>  - apply patch
>  - dpkg-buildpackage -S
>  - rename debian/patches/debian-changes- into something else
>and edit its headers
>  - fix debian/patches/series
> 
> Note: this works only if quilt is not installed (or if you ensure
> dpkg-source is called with --without-quilt which you currently can't pass
> via dpkg-buildpackage).

 Ah yes, again different workflows required - so we actually do need a
README.Source to warn people to not having quilt installed when working
with 3.0 (quilt) format? This sounds a bit backwards and strange, to be
honest.

> It's new, it's just that we haven't developed the toolset around it. I
> always expected that people would start developing new tools à la
> devscripts to make it easier for some specific scenario.

 Expecting others to jump the wagon isn't something you should depend
on, you are well adviced to be ready to do the work yourself in case
your expectations are over the top. :)

> Well, everything has a learning curve. It's normal to have to learn once.
> The point of README.source was to document stuff that not all DD are
> supposed to know. Knowledge of the new source format will be common
> in the near future.

 Given that there seems to be different workflows needed and required
depending on what packages one has installed I still see the need for
that, to be honest ...

> Well, people familiar with quilt have it already installed. And most
> packages are built out of VCS with patches un-applied so it doesn't even
> matter in most cases.

 That's unfortunately still evading the problem at hand. dpkg-source
isn't giving well-defined results, it acts differently with different
stuff installed. :/

> I have nothing against adding quilt to dependencies of dpkg-dev but I can
> tell that I will get the same number of grumbles from other people equally
> unhappy with that choice.

 Wouldn't it be possible to make dpkg able to create the .pc directory
with the stuff quilt needs to know? That would produce a well-defined
result and not different results on different systems.

 So long!
Rhonda


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

mass RC bugfiling due to removed apache1 packages

[Gerfried Fuchs]

Hello!

 Due to the removal of apache1 packages from the pool (including
libapache-mod-perl) quite a lot of packages aren't installable/buildable
anymore due to missing (build-)dependencies.  I'm preparing a massbug
filing for those so the maintainers are aware of that their packages are
RC due to this and either send the ftp team a bugreport about removal of
them or update them to work with apache2 instead/drop support of apache1
if apache2 support is already included.

 This is the notification per policy, I'm not yet done with the package
list and mail writing, so feel free to beat me over the head now before
I sent them, if you have to - but pretty please also tell me why.  :)

 So long,
Rhonda


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

Bug#490231: ITP: 2h4u -- mixed game of tetris and breakout

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: 2h4u
  Version : 1.3
  Upstream Author : Pierre Lagouge, Pierre-Yves Ricau
* URL : http://www.piwai.info/2H4U.html
* License : GPLv2+
  Programming Lang: C++
  Description : 2h4u -- mixed game of tetris and breakout

This game is a mix of Tetris and Breakout where you need to play both
games at the same time. You need to keep the ball up while trying to get
rid of as many lines as possible. Various bonus pieces drop and can get
catched with the Breakout bar.

 So long,
Rhonda, on behalf of pkg-games team



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

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Gerfried Fuchs]

* Florian Weimer  [2008-12-29 15:01:19 CET]:
> * Theodore Tso:
> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> > Social Contract, which I objected to them, and I still object to now.
> > If there was a GR which chainged the Debian Social contract which
> > relaxed the first clause to only include __software__ running on the
> > Host CPU, I would enthusiastically vote for such a measure.
> 
> I think it's not that simple anymore.
> 
> For instance, while I have no particular opinion on firmware, I object
> to packages in main which, when run on a web browser, execute
> proprietary Javascript blobs (either by shipping them in the package,
> or by linking them in some way).

 But it is. The web browser does run on the Host CPU, thus the
javascript engine does run on the Host CPU, too.

 Problem solved. :)
Rhonda
P.S.: Was there a MF'up2 anywhere? Not sure if this should/has to
   continue on both lists?
P.P.S.: Weren't the Results usually mailed to d-d-a, too? Was this a
   mistake here, or is my memory flawed?


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

Bug#453448: ITP: qcake -- programming environment and scene editor for 3D games

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs <[EMAIL PROTECTED]>


* Package name: qcake
  Version : 0.6
  Upstream Author : Harald Krippel <[EMAIL PROTECTED]>
* URL : http://www.qcake.org/
* License : GPL v2 or later
  Programming Lang: C++
  Description : programming environment and scene editor for 3D games

QCake (GPL) is a programming environment as well as a scene editor for
3D games based on PLIB (TM). QCake will support almost all PLIB
functions.

Currently implemented features:

* Plattforms: Linux, Mac OSX, Windows
* Hierarchical object tree
* Non-blocking scene display with PLIB
* Lens flare, fire and fog
* Particle and wave systems
* Cameras
* Project file using XML-OPML format
* Player controlled by keyboard, mouse and joystick
* Physics and Collision with ODE
* Barrier Object
* Body Object
* Player camera: TV, 2D, Ego modes
* Dynamic sky
* SPL scripting language
* 3D sound with OpenAL
* Sound- and object catalogue
* GUI with PLIB user interface
* md2 bone-animation
* Pathfinding with AStar
* pixel and vertex shader with GLSL
* QCake-Player to release your project

 So long,
Rhonda



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

Re: Recent changes in dpkg

[Gerfried Fuchs]

Hi!

* Philipp Kern  [2010-05-27 08:11:36 CEST]:
| As far as I understood it, it's not that much about unpacking, because
| the format is pretty clear then, but about packing (or in this case
| repacking) the source package.  There you should be explicit in what
| you mean because future versions of dpkg might abort if the source version
| is not explicitly specified in the package.

 Why is that needed? It always was explicit that 1.0 is meant, what's
the need for the change?

| Now I think the maintainers did outline why they want that in the past. :P

 Why they want it unfortunately is a wrong reasoning - the actual
pending and still unanswered question is "why it is needed". They
want people to switch to 3.0. By forcing to put something into
debian/source/format people start putting 1.0 in there for no gain. I
still fail to have received any real answer why debian/source/format
"1.0" containing is better than no debian/source directory at all.

 Making it mandatory does break existing behavior, even though I was
told that it won't happen "before all packages do have it". Fortunately,
there isn't only packages in our pool, so that point will never be
reached, and forcing people to put it in there out of principle with no
actual outlined reason on *why* doesn't help.

 Thanks,
Rhonda


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

Re: Recent changes in dpkg

[Gerfried Fuchs]

* Philipp Kern  [2010-05-27 09:05:39 CEST]:
> But I guess we already determined that automatic detection of various
> things isn't always the best choice.  Making 1.0 non-native and 1.0
> native explicit wouldn't sound too wrong.  :P)

 Unfortunately, dpkg doesn't support that - thus adding
debian/source/format "1.0" is no gain at all over leaving the file out
completely. Making the file mandatory thus doesn't gain anything, at
all.

 Thanks,
Rhonda


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

Re: Recent changes in dpkg

[Gerfried Fuchs]

Hi!

* Raphael Hertzog  [2010-05-27 10:05:51 CEST]:
> Yes, we're starting a long-term migration that will require every
> package to be modified. The reasons are that the dpkg maintainers
> consider the format 1.0 to no longer be a desirable default for
> dpkg-source given the availability of improved formats. We also
> acknowledge the fact that there's no longer a single format that suits
> all cases and as such we want the maintainer to be explicit about the
> choice they make.

 Requiring the file won't get rid of format 1.0 but will make people put
1.0 into debian/source/format. Planing to make the file mandatory might
indeed make more people think about it, though having the file won't
make the format 1.0 go away. There are already quite some packages in
the pool which explicitly have put 1.0 into the file - thus stating that
your approach to deprecate 1.0 with making the file mandatory is on the
losing end.

 So what is the real goal of making the file mandatory, your above
stated reason is unfortunately not working out?

> No, we won't break packages, it's a migration and dpkg-source will be 
> switched only when all packages have been modified.

 What do you include in the set of "all packages"? All packages in the
Debian pool? All packages that derivates might have? All packages that
commercial software developers offer? You are hopefully very well aware
that Debian isn't the only distribution or development body that uses
the .deb format.

> And 1.17.x means squeeze+2. And at that time, 1.0 will still be supported,  
> it's just that it won't be assumed if debian/source/format is absent.   

 And again, explicitly, I would like to know what the real benefit of
this change is that would *then* break building source packages, when
1.0 itself isn't planned to get deprecated.

 Thanks,
Rhonda


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

Bug#583368: please support .orig.tar.bz2 for source format 1.0

[Gerfried Fuchs]

Package: ftp.debian.org
Severity: wishlist

Hi!

 It would be very helpful if the dpkg source format 1.0 could also allow
.orig.tar.bz2 packages in the archive. The reason for the request should
be quite obvious - more and more upstream packages are shipped in bzip2
compressed tarballs. Given that conversion to 3.0 might not always be
the best idea just for the benefit of being able to use .orig.tar.bz2 it
would be great if the same could be allowed for source v1, too.

 Thanks in advance for considering,
Rhonda



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

Re: xulrunner 1.9.2 into sid?

[Gerfried Fuchs]

Hi!

* Michael Gilbert  [2010-06-29 21:50:31 CEST]:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> > Am 29.06.2010 17:24, schrieb Michael Gilbert:
> > 
> > > No, my proposal is to move the package to a better home: backports.
> > 
> > You don't know the current policies WRT packages in backports and about
> > their reasoning, do you?
> 
> I believe I do.  Backports are for recompilations of unstable packages
> for the stable releases.

 Thanks for excellently stating that you do *not* know about what is
backports about and for, you couldn't have done that better.

 Also, weren't it you who responded to a mail about getting the security
tracker informations straight that it is too much of trouble for you to
check backports informations, too? I fail to see how that would get
better if you want to push more stuff into backports?

> Honestly, the ideal solution would be for either backports or volatile
> to become officially supported (which from what I can tell has been in
> discussion for a long time now). In fact, if one or the other did become
> official, there would be no need for both.

 Also, you seem to know pretty little about volatile, it seems. Can you
please check the things you talk about before you are spreading false
statements just as they were facts?

 And no, the scope of volatile and backports is pretty much different,
none of them would obsolete the other.

 Thanks,
Rhon*please do your homework*da
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


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

Re: xulrunner 1.9.2 into sid?

[Gerfried Fuchs]

* Philipp Kern  [2010-06-28 11:55:22 CEST]:
> On 2010-06-28, Marco d'Itri  wrote:
> > If there is no manpower to do better than this then I feel that it would
> > be more honest to just use volatile.
> 
> The catch-all for "I can't maintain this stuff properly"[1] is not volatile,
> but backports.  Thanks.

 No it isn't, can you please stop disregarding backports in that way? If
you don't like it that's your fault - but calling it a dump place for
stuff that one can't maintain properly couldn't be further from reality.

> [1] No offence meant for the awesome mozilla maintainers.

 But offence meant for the backports maintainers? Thanks for the fish.
Rhonda
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


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

backports and volatile (was: Re: xulrunner 1.9.2 into sid?)

[Gerfried Fuchs]

Hi!

 I'd like to excuse for the style of my initial response, it was pretty
terse and just pointed out the misinterpretations without offering
corrections to them. I'd like to address them now.

* Michael Gilbert  [2010-06-29 21:50:31 CEST]:
> On Tue, 29 Jun 2010 20:58:11 +0200, Alexander Reichle-Schmehl wrote:
> > You don't know the current policies WRT packages in backports and about
> > their reasoning, do you?
> 
> I believe I do.  Backports are for recompilations of unstable packages
> for the stable releases.  Hence, that's why it seems like a good
> solution here.  volatile seems like it has a much more restrictive set
> of criteria, but I suppose it would also be a good solution if its
> allowable.

 That's not completely true. For a start, it's for recompilations for
packages from *testing* (not unstable) in a stable environment. But
reducing it to that is missing the point: The purpose of backports is to
offer newer features in packages that are intended for the next stable
release available for the current stable release.

 Wanting to put a package into backports as sole place won't get
accepted because it won't be part of the next stable release. If we
don't want to release a package it shouldn't go there neither.

> Honestly, the ideal solution would be for either backports or volatile
> to become officially supported (which from what I can tell has been in
> discussion for a long time now). In fact, if one or the other did become
> official, there would be no need for both.

 It might have evaded you, but volatile _is_ officially supported, for
quite a long while already. See  about
it, it uses .debian.org ressources directly. backports just started to
get into there with being integrated into the official buildd network,
things are progressing slowly.

 I only can see that you mean "officially supported *by the security
team*", neither of them is, which is true. I am very grateful that the
security-tracker does include the status for backports, though - that's
extremely helpful to track issues. Additionally though, they are also
both neither integrated into the BTS, which is another quite unfortunate
state.

 But there is *need* for both: While backports is for getting newer
features into stable for otherwise already good working software, the
purpose of volatile is a completely different: It is about getting
software into shape that does _not_ work anymore properly in stable
anymore but would require deeper changes than just a small patch that
could get in easily through a point release.

 Yes, clamav is a very good example here: The required engine changes
are too much for a security/point release update, thus volatile is the
proper place for it.

 I hope this clears up some confusion that might spin around in some
heads.

 Thanks, and sorry for the initial response style again,
Rhonda
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


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

Re: Purpose and policy of the future backports.debian.org.

[Gerfried Fuchs]

* Andrei Popescu  [2010-06-30 13:10:20 CEST]:
> On Mi, 30 iun 10, 12:58:25, Alexander Wirt wrote:
> > I'm strongly against that. I want packages properly tested and in your own
> > interest you should wait for testing migration of your packages. (of course
> > there can be exception, but not in general). 
> 
> Maybe the backports upload queue could automatically put the package on 
> hold until the unstable package has migrated to testing.

 I am working on setting such an upload queue up for myself and have
some code starters for that already. It just needs to get finalized.
Given that the "support contract" I mentioned in my blog did run out
this monday (and I have to say extremely successful :)) I think this can
go out for public testing soon.

 Enjoy,
Rhonda
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


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

Re: When and how can we migrate out of CVS and WML ? (Re: How to make Debian more attractive for users)

[Gerfried Fuchs]

Hi!

* Charles Plessy  [2010-07-29 16:53:18 CEST]:
> Le Thu, Jul 29, 2010 at 12:32:54PM +0300, Teemu Likonen a écrit :
> > * 2010-07-23 00:27 (+0900), Charles Plessy wrote:
> > > in my opinion, it is not only a question of design, but of
> > > infrastructure. For me, the combination of CVS and WML finally eroded
> > > all my motivation over the years for keeping some life in the pages
> > > under /devel/debian-med. I would welcome any change of VCS and
> > > language, even if it means losing the history or rewriting the pages
> > > from scratch.

 Rewriting everything from scratch would include losing translation
effort which is very huge. I actually don't welcome changes that tell
our translators technicly: "Thanks for your effort so far, but we throw
it all away."

 About change of VCS - there are (minor) efforts going on with respect
to try out wether git would work as backend. Any help is of course
appreciated, in any direction. I would welcome any change too, but to
some degree that sentence has the sounding of "if someone else does it"
added to it.

 As about moving away from WML: I am open for something that offers us
also the needed flexibility for pulling in automated information and
doesn't put too much burden onto our translators.

 Just to give you an idea what I am trying to avoid: the SPI website
changed from CVS + WML years ago, and was well translated at that time.
Go to  and try to find translated pages. Or
even other updates, the last News item reads 2008, all the resolutions
are gone from the site too.

 This is definitely not something that you'll find me appreciate or push
forward. Debian is an international community and wants, no, scratch
that, _needs_ to reach out to people in their native languages.

> > Yes, sometimes it's not enough to send patches to an established
> > project. Indeed starting a different (web) project, possibly with
> > different infrastructure, may be needed if one wants to change things.

 I would be really interested in ideas and discussions about possible
different infrastructure. I'm definitely not opposed to change (mind
you, that's why I am working on getting ,
 and 
deployed). Please speak up so we can properly discuss things. But please
understand that there is minimum requirements and simply throwing
everything away isn't a good idea.

> Indeed, I am starting to wonder if it would be possible to use redirections or
> aliases to allow a step-by-step transition…

 A how big list of redirections and aliases do you have in mind that you
want to have deployed to the mirror network? How many external links are
you willing to intentionally break by what's spinning around in your
mind?

> Instead of looking for volunteers to migrate the whole website,
> perhaps we should focus on giving flexibility for people who care
> about a particular branch to use a different system, provided that it
> follows some appearance and translation standards.

 Splitting the site into different smaller pieces that all do go their
own approaches, potential all in different directions, won't improve
things IMNSHO, and potential shy away translators for having to follow
several tiny bits.

 Or you have something completely different in mind and are just not
able to transport it in your writing - then pretty please try to
rephrase so that I can understand your proposal better.

> Perhaps this discussion should better be continued on debian-...@l.d.o…

 Yes, please let's keep such discussions on here, after all the list is
exactly for that. :)

 Enjoy!
Rhonda
-- 
"Lediglich 11 Prozent der Arbeitgeber sind der Meinung, dass jeder
Mensch auch ein Privatleben haben sollte."
-- http://www.karriere.at/artikel/884/


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

Re: Backports service becoming official

[Gerfried Fuchs]

Hi!

* Simon McVittie  [2010-09-06 19:33:34 CEST]:
> On Mon, 06 Sep 2010 at 17:52:17 +0100, Ian Jackson wrote:
> > What are the BTS limitations ?
> 
> I assume the relevant limitation is that in the BTS' data model, each source
> package has a single maintainer, whereas the maintainer of a backport isn't
> necessarily anything to do with the maintainer of the original package (who'd
> end up receiving backport-specific bug reports, if using the BTS).

 To me the solution is to see the person who does the backport as a part
of the packaging team. There is the need for having a communication
channel between the people anyway. Actually more and more packages are
moved into team maintenance and I'm pretty puzzled about the strong
objection on these grounds. And it would be very helpful for people that
store the packages in VCSes to have the backport changes in a seperate
branch so things won't get lost. It's IMHO the most natural thing to
do.[1][2][3]

[1] http://git.debian.org/?p=logcheck/logcheck.git;a=heads
[2] http://git.debian.org/?p=users/jgoerzen/bacula;a=heads
[3] http://git.deb.at/w/pkg/ejabberd.git/heads

 Yes, more than often enough bugs that appear in the backport do also
apply to the package in testing, so claiming that heaven would fall onto
our heads is pretty much uncalled for. In the outrageous most times
packages on backports don't have any changes, at all, and the bugs that
are only relevant for the backports version can be reduced to not
adjusted dependencies.

 I don't want to lie that bugs might not be backport specific. Just
recently the backport of iceweasel affected gnucash throug the new
libglib. This though was solved in close relationship with the involved
package maintainers and is thus a good example for how things can go
well.

 So the only limitation that really should bother us is the version
tracking. But then, like said, most bugs aren't really backports
specific, so setting a found version to the version without the ~bpo.*
part of the version string is easy to do for the time being.

 I really would like to see us trying to work together more effectively
instead of objecting to things right ahead without even knowing wether
it is such a big relevant deal to make a fuzz about. IMHO it isn't, far
from it.

 Of course, this is my private opinion and not enpowered with any hat or
role you might see me attached with these days. Even though I really
would wish that people would collaborate more.

 Enjoy!
Rhonda
-- 
https://flattr.com/thing/47066/Debian-BTS-cleaning-up


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

Re: Can you believe it? The Debian website has a new layout!

[Gerfried Fuchs]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

 This might be awkward, seeing a reply mail on debian-devel-announce,
but actually this response deserves to be in the broader public.

* Martin Zobel-Helas  [2011-02-06 02:54:02 CET]:
> After about 13 years[1] with nearly the same design, the layout and
> design of the website changed with today's release of Debian Squeeze.
> 
> This has been made possible thanks to the immense involvement over the
> years by Kalle Söderman and Gerfried Fuchs, who were tireless in their
> efforts to make the idea a reality, with the help of the webteam: Ben
> Armstrong, Damyan Ivanov, David Prévot, Francesca Ciceri, Kåre Thor
> Olsen and Simon Paillard.

 I personally like to thank all the involved people too, and could add
some messages on why they are named here, though more importantly this
reply is about one person missing, who was extremely supportive and
motivating (and at times pushing too) to get this done, and who seems to
be too humble to put himself into the list: Yes, this is about Martin.
He was one of the early adopters on <http://dsa.debian.org/> (probably
that's why he didn't mention that site - it's like this for months now
already).

 And to let you know, it isn't meant to stop here, there are still
services that are not adapted yet - and even though I am very happy that
a fair amout of other sites did already pick up the new theme anyway.
This tells us that we are on the correct tracks here, and is the best
feedback one could wish for. Just to let you know, the one major site
that our Distribution has and is also directly used and visible for 
 
endusers is not forgotten, bugs.debian.org is our next major target.

 Again, thanks to everyone involved, thanks to Valessio for spacefun and
thanks to Kalle for his tiredless work over several years without even
a proper feedback for the first years. That's the kind of long-time
contribution we are looking for in the project, and I'm quite confident
that it will pay off soonish.

 Thanks to everyone who spends so much time on the website, the
translations of it or Debian in general. You can see this as a promise
that the Website Team "ain't dead" and that big things are possible to  
  
get changed, even though it might look like an impossible task.

 Enjoy the new release, enjoy the new artwork, enjoy the new design.
Rhonda
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBCAAGBQJNTrUrAAoJEDH85+fdB5RhTc8H/A9PKHfKz9ysJOChYlhG+mBa
XEH7goDregqsWM+WfMZ4Tk0Fh42Xw08e4MThhfFIP7iA/gJSq3Lsk1hAQAvoAWdK
06GqInWSfom7tX1Hcaw8JRGp7ceoFVgUOAyLEZGDRXULbmzDTyo+Z/mHKUoHSgfd
zKswC9gKCzr5CzEaAkvJrNySYSq13L40RUDl5KHlVKzbVU1FOKOJHFnrHGVpQyMY
hss/oeE8q4391C8bDuk6jFSpiBuHSyDSRYHc7YLB85VwR7tn9EbG6COiZF1nWIIb
rB+I25c0gY8dHJ3mWo89uYMZVeEWrrYwjjF8EsMPKK8pVH6eXK9ZxjR22RU6uN4=
=jBLx
-END PGP SIGNATURE-


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

Re: Can you believe it? The Debian website has a new layout!

[Gerfried Fuchs]

* Gerfried Fuchs  [2011-02-06 15:53:55 CET]:
> Hi!
> 
>  This might be awkward, seeing a reply mail on debian-devel-announce,
> but actually this response deserves to be in the broader public.

 ... so much for trying it. ;)  And actually it makes sense. Though,
debian-devel is just as good, I'll try to remember this special setup
next time.

 Enjoy,
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


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

Re: enable/disable flags in /etc/default

[Gerfried Fuchs]

Hi!

 As someone who is also annoyed by the default file startup hack (which
is IMHO an abuse because why have a S rc link then?), let me also throw
in my 0.02 EUR.

> Stig Sandbeck Mathisen  writes:
> > The "short term" issue is figuring out if the current practice of
> > DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> > we want to keep doing.

 Actually I explicitly chose to not go down that path for
wesnoth-server. I settled for this approach:

dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'

 This sets the symlinks for the service to be disabled by default and
leaves it to the administrator to switch to S symlinks. Actually now
that I look at it I think I might have triggered a bug in update-rc.d
here, why does that only create K links in rc{0,1,6}.d but *not* in
rc{2,3,4,5}.d?

 Also, the update-rc.d foo enable hack seems to not work in this case,
it seems to depend heavily on the LSB information (and thus ignoring an
administrator's choise for settling for different runlevels).

 And being able to support the local admin is why I have to chose to set
the rc links to kill links by default: If they want to tweak their
runlevels they have to tweak the symlinks. If they have to touch an
*additional* default file they would get annoyed (actually, _I_ get
annoyed by that, having to tune the rc symlinks *and* the default file
to do it properly).

* Russ Allbery  [2011-03-02 00:20:52 CET]:
> > The "long term" issue is having a toolset, for the end user, for
> > starting and stopping services, enabling and disabling services when
> > booting, installing and upgrading, and setting a global policy for what
> > the initial status of an installed service should be.
> 
> Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> variables in some of my packages, I think you have the order reversed
> here.  I agree that those settings are horrible, but as horrible as they
> are, they're less weird than our current user interface for disabling init
> scripts.

 From a point of view that all runlevels are the same I would agree with
you. But actually there are different runlevels for a reason, and
personally I really would like to see Debian actually move forward on
that grounds, offering more useful runlevels which actually are
different by default like suggested in the LSB instead of having them
all do the same.

>  (Users have at least a hope of finding it, which is not really
> true in my experience of the init method at present.)  I'm therefore not
> inclined to remove them until we provide a non-horrible user interface
> that can really replace them.

 file-rc actually has a saner user interface in that respect from what I
understood.

> > What I'd like to be able to do, is to set a policy after system install,
> > and have all packages _obey_ this policy. :)
> 
> Yup, I think that's the right order.  :)

 Well, I personally don't like to treat _all_ packages the same, and I
don't think that this is just me?

 So long!
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


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

Possible sane approach? (was: Re: enable/disable flags in /etc/default)

[Gerfried Fuchs]

Hi!

 Some things usually spin in my head for days and I come up with an idea
that looks sane at first sight. This might be such a moment, and I
wonder wether there might be something that I overlooked here:

* Gerfried Fuchs  [2011-03-02 14:47:22 CET]:
>  Actually I explicitly chose to not go down that path for
> wesnoth-server. I settled for this approach:
> 
> dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'

 While this might look good at first sight, it has several deficits,
like the rc.d links aren't set for the regular runlevels (for whatever
reason) and update-rc.d foo enable doesn't work because that looks at
the LSB headers.

 So I came up with this thought for a postinst snippet:

#v+

# only on new install
if [ "$1" = "configure" ] && [ "x$2" = "x" ]; then
update-rc.d foo defaults >/dev/null
update-rc.d disable foo
fi

#v-

 Shouldn't that be a sensible approach with what options we currently
have? If there is some fault in my thinking, please point it out.

 Thanks,
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


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

Re: Possible sane approach? (was: Re: enable/disable flags in /etc/default)

[Gerfried Fuchs]

 ...

 Before someone starts to nitpick it and distract from the real content:

* Gerfried Fuchs  [2011-03-03 07:58:59 CET]:
> #v+
> 
> # only on new install
> if [ "$1" = "configure" ] && [ "x$2" = "x" ]; then
> update-rc.d foo defaults >/dev/null
> update-rc.d foo disable
> fi
> 
> #v-

 Of course foo disable, not disable foo.
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


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

Re: Disable ZeroConf: how to ?

[Gerfried Fuchs]

Hi!

* Bastien ROUCARIES  [2011-03-02 18:25:30 CET]:
> Does avahi could be disable (using kernel level firewalling is not
> from my point of view a solution) ?

 A nice hack that I was informed just recently about:

echo exit 0 >> /etc/default/avahi-daemon

 That will disable the daemon quite effectively.
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year." -- Julian Assange


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

bugs.debian.org: ChangeLog closes handling should be changed

[Gerfried Fuchs]

Package: bugs.debian.org
Severity: wishlist

Hi there!

 With the addition of the testing distribution we have new problems:
Bugs are closed in unstable but flow more or less slowly (due to
dependency problems) into testing, but are due to the uploads into
unstable long closed.

 What we need is a change here: Bugs should just be closed in unstable.
How to do this?  They should be rather be tagged  than be closed
by an upload to unstable.  Not unconditionally, of course.  The version
of the bugreport should be compared with the version currently in
testing.  Some sort of algorithm not too complex but able to handle most
of the cases shouldn't be too hard to do (yes, I volunteer to help
there).

 Secondly, the testing scripts should be tweaked, too.  They should
check the differences between the current changelog.Debian and the one
of the version that is going to flow in from unstable and close the
bugreports tagged .  Why only those?  To avoid messages tagged
sid that where retagged sid because of problebugreports tagged .
Why only those?  To avoid messages that were retagged sid because of
problems that are still in effect in unstable.

 Of course these sugguestions are not foolproof -- but the current
situation is neither.  I sugguest these changes to make the BTS a better
place to track bugs.  Current situation is far from optimal.  We
currently state that there isn't a bug anymore just by closing it with
an upload to unstable.  The fact is that is still is active in testing
and the BTS should live up to that fact.

 I hope that these sugguestion will hit some open ears.  I'm not really
sure if this is the best sugguestion, but it's the one idea I currently
came up with.  Feel free to comment on it, I guess discussion on
debian-devel (*without* the copy to the BTS directly) would be a good
idea, I am thinking of scanning the responses and mail summaries into
the BTS to keep the bugreport current.  If you like, Cc: me offlist if
really needed, I am not subcribed to debian-devel, but I'll watch the
discussion through both the webarchives and news:linux.debian.devel (and
answer from there -- need to finish my setup wrt/ that anyway ,).

 Thanks, and I hope some of the inner circle like the idea.
Alfie
-- 
php ist an sich ne recht nutzlose sprache wenn da nicht soviele dinge so
einfach drin moeglich waeren
-- Getty in #debian.de

Re: bugs.debian.org: ChangeLog closes handling should be changed

[Gerfried Fuchs]

* Brian May <[EMAIL PROTECTED]> [2002-08-29 09:50]:
> On Tue, Aug 27, 2002 at 08:48:31AM +0200, Gerfried Fuchs wrote:
>>  What we need is a change here: Bugs should just be closed in unstable.
>> How to do this?  They should be rather be tagged  than be closed
>> by an upload to unstable.  Not unconditionally, of course.  The version
   ^^^
>> of the bugreport should be compared with the version currently in
  ^^
>> testing.  Some sort of algorithm not too complex but able to handle most
   
>> of the cases shouldn't be too hard to do (yes, I volunteer to help
>> there).
> 
> Then bugs will me marked as sarge, even though they might be bugs
> specific to unstable.

 Just to make sure you didn't miss that I thought of that problem
already, thanks.  Or do you think of that the bugs are there because of
other packages in unstable?  Well, then the bug might be filed against
the wrong package.  Which would leave us with a problem -- the version
is rather meta information in the bugreport and not real useful data, is
it?  So currently there is no need to change the version field if a bug
gets reassigned to a different package... *hmmm*  Difficult issue, but
still no issue that shouldn't be raised/thought about.

> It would be much better to remove the sid tag when it gets uploaded
> to unstable, turn off the sarge tag when it goes into testing, and
> turn of the woody tag if it is lucky enough to get into stable.

 ... and if the final tag gets removed it should be closed.  Another
approach which seems to work quite well and might even live happily with
the current situation: Bugs with no tags simply get closed for they are
not tagged for a specific distribution.  Sounds good to me.

> (of course this assumes that the tags were already set, preferably when
> the bug is first reported)

 Of course.  And of course the whole BTS depends on reasonable users,
not on spam bots closing bugs just out of curiosity ;)   So I don't
think that's a real problem.  Maintainer that care for a good history of
the bugreports against their package should do that anyway.  Others who
simply don't care shouldn't be bothered if we take the second approach
because they won't usually tag their bugreports anway.

> PS. Please look at http://www.debian.org/Bugs/Reporting, and search
> for "X-Debbugs-CC".

 P.S.: Please look at the BTS archives for this mail, I did set
X-Debbugs-CC, just with the wrong value.  Mea culpa.

 So long!
Alfie
-- 
 I have  a little problem with a bug-report I received... *scratch*
 Alfie: I send those to /dev/null
  -- #debian-devel


pgpTQiEagD5Ux.pgp
Description: PGP signature

Re: debconf template translations from ddtp

[Gerfried Fuchs]

* Michael Bramer <[EMAIL PROTECTED]> [2002-11-27 00:21]:
>   We've started the translation of debconf templates some weeks ago.

 Good to see that those are coordinated now, too.

>   If you are a package maintainer, you can obtain a package-related
>   file from
>   http://ddtp.debian.org/debconf/maintainer/$PACKAGE with more
>   information. 

 It would be nice if it can be sorted by $MAINTAINER, too.  I dislike
the idea to have to look for every single package instead of having a
pool for all of my packages.

 Have fun,
Alfie
-- 
   char *strstr(const char *haystack, const char *needle);
  -- STRSTR(3)  Linux Programmer's Manual


pgp7GgVDBucJC.pgp
Description: PGP signature

Re: Are we losing users to Gentoo?

[Gerfried Fuchs]

* Joey Hess <[EMAIL PROTECTED]> [2002-11-28 17:13]:
> So maybe you click on the "Debian on CD" link, right? And from there on
> the 4th bulletted link ("Download CD images using HTTP or FTP"), after
> wading past unofficial minimal CD images, and learning what jigdo is.

 Because those options are prefered.  We still like to help the sensible
users instead of doing everything for the DAUs[1] who simply don't care,
don't we?

> And then on scroll way down the list to your country. And then into the
> current directory on the mirror, oops, that was jigdo only?!  back out
> and to the 3.0r0 directory.

 Uhm, just a second.  When I click a on the links in that list I get to
the debian-cd directory on the mirrors where I can choose between jigdo
and the 3.0r0 directory.  Why do you find yourself in the jigdo
directory?

> What, that was jigdo again?! Hmm, try another mirror.

 Now it would be _more_ than helpful which link you are refering to.
Without knowing it that seemingly broken link can't be fixed, thank you.

> Maybe the one in Austria, because it's the top of that list of
> mirrors. Hmm, no, it only has a jigdo directory too.

 Uhm, you seem to be blind, sorry.  Both ftp and http of the austrian
mirror has the 3.0r0 directories.  Can you please check before accusing?
I guess you seem to be puzzled by the layout of the HTML-Page there --
but you can't accuse debian for third party layouts, or do you try to do
so?

> Finally, by picking the FTP site (not the HTTP site) in Austria, and
> digging two more directories deep, you find an iso.

 "Digging" one directory, there are just two and it's the one that is
not named jigdo.

> But maybe instead, back at debian.org's front page, you picked the
> "Getting Debian" link instead. Only to end up on a page that links to cd
> vendors and "downloading over the Internet". Ok, the latter. But it
> points to a page that only lets one download unnofficial netinst iso
> images, which are of varying quality, and well, unnoficial.

 You are right, there should be added a link to the $(HOME)/CD/http-ftp/
on that page, too.  Thanks for the (quite hidden) suggestion.  Joy, do
you think that would help, too?

> (feel free to use me as one data-point; I have never used the debian
> website to try to download a debian CD before; indeed I have never
> downloaded a debian CD).

 But your first approach was correct, only that you seem to have been
confused by third party html layouts on which we don't have any
influence.

 So long,
Alfie

[1] Dumbest Assumable User
-- 
16:46  sorry fuer die andauernden rejoins
16:46 -!- Molle [EMAIL PROTECTED] has quit [leaving]


pgprm91hmbW2S.pgp
Description: PGP signature

Bug#171419: ITP: libdbix-abstract-perl -- DBI SQL abstraction

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist

* Package name: libdbix-abstract-perl
  Version : 1.003
  Upstream Author : Andrew Turner <[EMAIL PROTECTED]>
* URL : CPAN
* License : Like perl: GPL or Artistic License
  Description : DBI SQL abstraction

 This module provides methods for retrieving and storing data in SQL
 databases.  It provides methods for all of the more important SQL
 commands (like SELECT, INSERT, REPLACE, UPDATE, DELETE).
 .
 It endeavors to produce an interface that will be intuitive to those
 already familiar with SQL.
 .
 Notable features include:
  * data_source generation for some DBD drivers.
  * Can check to make sure the connection is not stale and reconnect if
it is.
  * Controls statement handles for you.
  * Can delay writes.
  * Generates complex where clauses from hashes and arrays.
  * Shortcuts (convenience functions) for some common cases. (Like
select_all_to_hashref.)


 Very helpful IMHO, but I'd like to know if people would use it.  I have
already packaged it for myself so rather take this bugreport/mail as a
vote for wheter this would be a useful addition to the pool or just a
waste of disk space.  If the later I would still keep it in my private
repository.

 Have fun,
Alfie
-- 
tar: Cowardly refusing to create an empty archive

Re: Are we losing users to Gentoo?

[Gerfried Fuchs]

* Thomas Bushnell, BSG <[EMAIL PROTECTED]> [2002-11-29 10:27]:
> But I use the website.  Here's a questions.  Go to eh redhat site and
> see if you can figure out where to get a complete RedHat CD downloaded
> from the net?

 Uhm, should that have been a statement pro or contra to our page?  I
found it quite easy:

 -) Download link in the top row, righthand side.
 -) "How to Download Red Hat Linux 8.0"
 -) "Download the files you need"
 -) --> Downloading the ISO Images

 Or am I thinking too straight?
Alfie
-- 
"The reason why worry kills more people than work is that more people worry
 than work."
  -- unknown


pgpSk5t16Mksq.pgp
Description: PGP signature

Re: Database-specificisms considered harmful

[Gerfried Fuchs]

* Matthias Urlichs <[EMAIL PROTECTED]> [2003-04-11 14:34]:
> Personally, I do not like all those -mysql, -pgsql, -whatever packages.
> 
> Whatever happened to the idea of using a common database access library
> like iODBC? It's reasonably small, Not A Burden if you happen to not
> require any database lookup features, and it doesn't bloat the archives
> with four versions of exim (-none, -mysql, -pgsql, and -kitchensink).

 Thats a really nice idea.  Are you going to send in patches for the
various programs to support that?

 I mean, yeah -- it is really a nice idea, but someone has to do the
work for it.  If a program supports it already I would expect the
maintainer of the package to do the reasonable thing and enable that
sort of binding.  If it on the other hand doesn't, are you willing to
work on that part to get the support in?

> Personally, I would consider adding an appropriate paragraph to Policy.
> Something along the lines of
> 
> * Programs which access SQL databases should do so through
> libgda2/unixodbc/???.

 Again, nice idea, but I don't think that it will help. You can't
dictate upstream what to work on, and I don't know if the usual
maintainers of such packages are skilled/motivated enough to produce
the needed changes themself.

 So long!
Alfie
-- 
mknod /dev/aha c sky earth
  -- me, 08/2000


pgpxFroRk1Dgh.pgp
Description: PGP signature

Bug#188960: ITP: mangband -- multiplayer text-based rogue like dungeon simulation game

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist

* Package name: mangband
  Version : 0.7.2a
  Upstream Author : Robert Seifer <[EMAIL PROTECTED]>
* URL : http://www.mangband.org/
* License : see the file COPYING in the source tarball:
non-free as in for non-commercial use only
  Description : multiplayer text-based rogue like dungeon simulation game

 MAngband is a multiplayer game based on Angband. It works through a
 metaserver where new servers register. A server program is included in
 the package, so you can set up your own server and play there with your
 friends.
 .
 Angband is one of those games that are rogue like: A dungeon explore
 game with a textual frontend.


 I've mailed with crimson about the mentioning of the GPLed xpilot code
in the COPYING file and he told me that all of the xpilot networking
code was replaced since then so no GPL violation happened there.

 I personally would really prefer if the thing would be more DFSG free,
but the Moria/Angband code is that old with tons of contributors that it
isn't possible to change it.  Although there are efforts to produce a
GPL version of Angband, from which MAngband (and of course the Angband
package itself, and Zangband) could profit in the long term:


 Have fun,
Alfie
-- 
 Von uns allen bleibt nur Asche. Nur die DWN wird man in hundert Jahren 
  noch nachlesen koennen.

Re: Debian Developer LDAP

[Gerfried Fuchs]

* Oohara Yuuma <[EMAIL PROTECTED]> [2003-04-15 07:50]:
> On Mon, 14 Apr 2003 10:24:44 -0400,
> Mark Bucciarelli <[EMAIL PROTECTED]> wrote:
>> (3) is the email gateway used?
> I tried but failed to change my latitude/longitude data.
> None of the following worked.  RTFM instructions welcome.

 RTFM .  From db.debian.org
frontpage -> Documentation -> Mail gateway

> Lat: +0334500., Long: +1303000.

 The , must have been the problem.

> Lat: 33:45:00.000 N Long: 130:30:00.000 E
> ---
> Lat: 33n45. Long: 130e30.
> ---
> Lat: +0334500 Long: +1303000

 Those are simply in wrong format.

> The error message was:
> ==> Message Error: Positions were found, but they are not correctly formed
> Command is not understood. Halted

 The mail gateway should include the above URL to the documentation to
avoid such questions in the future.  Who can add it, please?

 So long!
Alfie
-- 
Nachdem es SuSE nun endlich geschafft hat, Linux so sehr zu verunstalten, daß
es schlechter als Windows ist, bootet es nun also sogar schon auf der Hardware
von Microsoft.
 -- realborg zu 


pgpDnpiXbSF5X.pgp
Description: PGP signature

Re: [debian-devel] Status of mICQ code audit

[Gerfried Fuchs]

* Glenn Maynard <[EMAIL PROTECTED]> [2003-04-23 03:30]:
> If someone missed a meeting because a program they installed out of
> Debian had a time bomb in it, they would be justified in questioning
> their use of Debian, not just the application.

 No.  They would be justified in questioning their opinion in their
usage of _un_stable for critical services without a clue about what to
do in such a case (like keeping former version (dpkg-repack) or taking a
look at  for older packages).

 There were _bader_ breakages in unstable than a single application.

 People depending on services on the one hand and using unstable on the
other hand should never blame the project for anything.

 Get a clue if you plan to live with unstable.
Alfie
-- 
 installations anleitung für intelx86 richtig ?
 Angel`Eye: Kommt auf deinen Rechner an. Wenn du die Antwort nicht weiß,
   ist sie ja.
-- #debian.de


pgpWzIwukyIHz.pgp
Description: PGP signature

Re: Please notify the maintainers when removing packages

[Gerfried Fuchs]

* Sven Luther <[EMAIL PROTECTED]> [2003-05-07 12:18]:
> On Wed, May 07, 2003 at 09:44:54AM +0200, Gerfried Fuchs wrote:
>>  But they *should* read the bug mail they receive, and I guess that was
>> Michaels point. If they don't read their bug mails they don't seem to
>> care about their package anyway.
> 
> Yes, sure. But then again, we only have so much free time, and we
> prioritize it differently. It happened for me back then, with the
> active-dvi package. At the time there was a FTBFS bug or something such
> not really all that problematic, and i knew there was going to be a new
> upstream release nextly.

 Well, usually FTBFS bugs _are_ problematic, if people aren't ignorant
about other architectures than their own.

> If i had not noticed it, the package would have been removed without
> any kind of information to the maintainer, and i would maybe not even
> have noticed.

 What makes you think so? I can't follow the reasoning for why you think
that it would have been removed right then.

> We maintainer are recommended to have good comunications channels to our
> upstream, but i suppose that the release manager should have good
> comunication channels to the different maintainers to, which doesn't
> seem to be always the case.

 O.k., I can understand that request and it makes sense. I was just
under the impression that the "Release Update" mails that the RM sent
are much more informative and important to read than the weekly RC bug
list.

> Also, i understand that they are also MIA maintainers, or semi-MIA ones,
> and that for them it will not make much of a difference, but if we help
> out even one good-intentioned maintainer, it is already a good thing.

 The MIA maintainers are a big problem on their own, unfortunately. We
definitely should get rid of them or at least be able to get some
informations from them to see when they will have time again and suspend
them somehow. But that was discussed already quite intensively...

>>  If the users may be interested in the package they definitely *should*
>> subscribe to d-d-a.  d-d-a does *not* only address the debian developers
>> but all the people that are interested in the development of debian in
>> general. That is, also those interested in any single package.
> 
> But the bug scan package is not in any readable form. It mostly says the
> same as last week. If some kind of diff where available, it would make
> more sense to read it.

 And again I was not talking about the bug scan mails, I was speaking
about the "Release Update" mails. I still have the impression that a
REMOVE tag in the bug scan mail doesn't mean much but just an indicator
on how long a RC bug might be open already. I am still not convinced
that packages actually were removed with *only* the REMOVE notification
in the bug scan mail. Noone has showed me yet that this impression is
wrong.

 About the idea of "some kind of diff" you got me interested. I might
want to take a look on what can be done on that point. Maybe something
like (EXAMPLE, there are no such bugreports):

Package: t-prot (debian/main)
Maintainer: Gerfried Fuchs <[EMAIL PROTECTED]>
New: [REMOVE], 0815 [ + ]
Changed: 4711 [P  ] (+P)

 If there are no new RC-bugs or no changes the package shouldn't be
listed, if I get you right. I'll take a look on the original script, if
I can find it.

> It is easy to say that everyone should fix bugs, respond quickly to
> mails, and so one, but the people saying it should be held to the same
> standard.

 I try as good as I can ;)

> Then mail the debian maintainer that you are going to remove their
> package, is that asked too much ?

 Some developers seem to consider every additional mail by default as
spam and object to anything in that respect. But don't get me wrong, I
understand your point here.

> And beside, it is basic courtesy, but then i have long known that some
> of the most important debian people have a tendency to be quite rude
> to other developpers. Did i tell you how i got blacklisted by James
> Troup when i was too eager to find the reasons for build problems he
> told me about in not so clear ways.

 It seems to be a special sort of "manners" when your higher up,
sometimes. Have been in some infight with one of the uppers, too. It's
just that because one is longer in the project it doesn't mean that s/he
can't be wrong...  (and that is no judgement of your problem with elmo;
I don't know anything about it)

> Well, but if you don't get properly informed in the first place, you may
> not notice, and not everyone can pass hours each day to read all the
> debian information.

 Scanning for ones name in the weekly bugscan mail isn't that time
intensive, so don't overdo it.

&g

Re: security in testing

[Gerfried Fuchs]

[Removed debian-private from Cc-List, there is *no* need to duplicate
 the thread there]

On Fri, May 16, 2003 at 07:58:44AM +0200, Sven Luther wrote:
>   2) a way for people for which stable is too outdated to run more
>  advanced software, without suffering from the breakages of unstable.
>  By saying this we clearly imply that it is better to run testing
>  than unstable.

 Sure, but we _still_ tell people that care for security *to run
stable*.  Noone was ever told that unstable is secure and should be used
for critical services

>  Sure, this was before we had time to test testing,
>  and before we became aware of the big stalls implied, and the fact
>  that security wise testing is worse than unstable.

 And still, unstable _is_ bad according to security. We do NOT encourage
people to run unstable for secure machines, so why do you think that
telling people to rather use testing than unstable for not-secure things
is a bad idea? Just take the long time that the kde2 package in unstable
were still vulnerable because their maintainers thought that kde3 will
make it soon into unstable (or whatever the real reason was -- the
reason doesn't really matter, so don't pin me down on that).

> This second goal is today a total failure,

 I don't think so.  Security was never part of that second goal.

> I still think that the second goal can be achieved. Probably the fact to
> use testing-proposed-update for security and RC bugs would be enough, i
> don't know, only experience will tell.

 Some people stepping forward to do actual work on that part would be
needed, than it might be enough. People repeating the same phrases and
accuses over and over again are not enough, though.

 So long,
Alfie

Re: security in testing

[Gerfried Fuchs]

On Fri, May 16, 2003 at 12:15:48PM +0200, Sven Luther wrote:
> Yes, but before someone steps for and does this, a consensus need to be
> found on what to do, the RM at least has to green-light it, and it
> should be announced on debian-devel-announce so all the maintainer are
> aware of it and the rules that apply to doing it.

 No, you can't announce something on dda that doesn't exist. That's
nonsense. Pretty please announce things that already started working and
showed worth it, thanks.

 So long,
Alfie

Bug#112754: ITP: mlvwm -- Macintosh Like Virtual Window Manager

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
thanks
[Cc me on replies, I'm not subscribe to debian-devel]

Hi!

Description:
 mlvwm is a window manager for X11 designed to look and feel like the
 Macintosh environment. It provides multiple desktops, separate menu
 bars for different applications, and the ability to interact with
 applications from that menu bar. It does this by sending key sequences
 to the application, such as ctrl-X or alt-Y.

Copyright:
   Copyright 1988 by Evans & Sutherland Computer Corporation,
  Salt Lake City, Utah
  Portions Copyright 1989 by the Massachusetts Institute of Technology
Cambridge, Massachusetts

   All Rights Reserved

Permission to use, copy, modify, and distribute this software and
its documentation  for  any  purpose  and  without  fee is hereby
granted, provided that the above copyright notice appear  in  all
copies and that both  that  copyright  notice  and  this  permis-
sion  notice appear in supporting  documentation,  and  that  the
names of Evans & Sutherland and M.I.T. not be used in advertising
in publicity pertaining to distribution of the  software  without
specific, written prior permission.

EVANS & SUTHERLAND AND M.I.T. DISCLAIM ALL WARRANTIES WITH REGARD
TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES  OF  MERCHANT-
ABILITY  AND  FITNESS,  IN  NO  EVENT SHALL EVANS & SUTHERLAND OR
M.I.T. BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL  DAM-
AGES OR  ANY DAMAGES WHATSOEVER  RESULTING FROM LOSS OF USE, DATA
OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
TORTIOUS ACTION, ARISING OUT OF OR IN  CONNECTION  WITH  THE  USE
OR PERFORMANCE OF THIS SOFTWARE.

 That makes it suitable for main, if I don't misread it.  Furthermore I
found out that even it looks quite nice it doesn't consume much memory.
But find out yourself.

 I'd also like to notice that due to this package I might package xap
too, the X Application Panel.  Not decided yet, stay tuned for
stand-alone ITP on that topic.

 If you think that this package isn't really needed and would just
pollute our server (although it's really small in size) just let me
know, too.

 So long,
Alfie
-- 
 You never learn anything  |   /"\   ,'~~.
   by doing it right.  |  / chaos \  alfie.ist.org   |o ?~\
   -- unknown  |  \inside!/  [EMAIL PROTECTED]  /_   ~<\
   |   \_/   \__,~ \>

Re: Graphing Debian Lists

[Gerfried Fuchs]

Hi!

[Cc me on replies, I'm not subscribed]

On Thu, Sep 20, 2001, Martin Schulze wrote:
> Gathering data happens all 30 minutes and I've let it run for a couple
> of days before making this annoncement, so there are some data to
> show.

 It looks strange that it seems that debian-devel-announce seem on the
first look to have had no subscribers before you started.  On the second
look one sees that the bottom of the image is not zero.  Could you
please change it that it has the zero-point in the graph so the graphs
can be looked in a _real_ manner and are not some "hey - look at that
curve!" graphs?   That's the first big lies that any statistic tries to
make, and we shouldn't do that, IMHO.

 Even you might note on the most lists then just flat lines it makes
more sense and doesn't leave the people like "Hey, they just seem to
have started that list, there is a high flow of subscritions in it"...

 Just a thought.  I like the graphs very much.  It's meant constructive,
not destructive.

 Thanks,
Alfie
-- 
 You never learn anything  |   /"\   ,'~~.
   by doing it right.  |  / chaos \  alfie.ist.org   |o ?~\
   -- unknown  |  \inside!/  [EMAIL PROTECTED]  /_   ~<\
   |   \_/   \__,~ \>


pgpUi4RooZaex.pgp
Description: PGP signature

Re: Graphing Debian Lists

[Gerfried Fuchs]

Hi again.

On Fri, Sep 21, 2001, Martin Schulze wrote:
[zeropoint or not - that's the question]
> That's not giving us anything.  It doesn't draw a picture of the
> subscribe frequency, nor does it provide a better view of the number
> of subscribers.

 Well, it _does_ draw a picture of subscribe frequency, related to all
the people already subscribed.  If you want a picture of just subscribe
frequency, than make that:  With the zero-point in the middle, and
subscriptions add and unsubscribes substract from there.  A graph for a
statistic is worth nothing if it doesn't have the zero point in it.
First unit statistics lesson.

> In fact, the graphs would be quite flat and uninteresting.  The first

 But it would be a real graph.

> version on murphy had them, since the rrdtool in potato was too old.
> As an example check out these two graphs of debian-announce.
> 
> http://people.debian.org/~joey/stuff/debian-announce-distabs-month.png
> http://people.debian.org/~joey/stuff/debian-announce-distabs-normal-month.png

 These doesn't seem to be the first graphs with the zero in it.  So the
still offer a false view of the state.

 I don't exactly know whom you want to impress with those false graphs
or what you want to be able to see from it - but the current state seems
to miss that, IMHO.

 Just my thoughts, nothing personal, as you should know.  Go on like you
like, personally I see it in this way quite useless.

 Alfie
-- 
 You never learn anything  |   /"\   ,'~~.
   by doing it right.  |  / chaos \  alfie.ist.org   |o ?~\
   -- unknown  |  \inside!/  [EMAIL PROTECTED]  /_   ~<\
   |   \_/   \__,~ \>

Re: DEBNAME or DEBFULLNAME?

[Gerfried Fuchs]

[please copy me on replies]

* Rob Bradford <[EMAIL PROTECTED]> [2002-01-02 20:03]:
[DEBNAME vs DEBFULLNAME]
> I filed a bug against devscripts (#115601) ages ago about this, i got
> bitten nastily by this. I personally prefer DEBNAME.

 It seems that we can't get a consensus  Which "some other tools"
are those you were speaking of in that bugreport?  I have only got
answers regarding DEBFULLNAME but none regarding DEBNAME.

 I personally would like to have DEBNAME also - but that's not our call.
There is a broader mass (of programs) that seems to be using DEBFULLNAME
than DEBNAME (still, I only know about reportbug) so I'm about to file
it as bugreport against that package for the start.

 So long,
Alfie [trying to destroy inconsistencies and not plant bad blood]
-- 
I don't know, chmod g+a something  and the world goes crazy :)
  -- Craig Small, [EMAIL PROTECTED]


pgpvbpLQR1kuF.pgp
Description: PGP signature

Re: bogus maintainers?

[Gerfried Fuchs]

* Josip Rodin <[EMAIL PROTECTED]> [2002-01-03 21:06]:
> On Thu, Jan 03, 2002 at 08:37:31PM +0100, Bas Zoetekouw wrote:
>> What I meant was: the page was apparently generated from local data
>> (from a local /var/lib/dpkg/available perhaps?).
> 
> And I said it _was not_.
> 
> The broken package really was in sid, my few-days-old sid still has it.
> It's been fixed in the meantime. The devel/people page will be regenerated
> shortly.

 And to be honest - you could have tried to check the Packages file you
get from debian archive.  The info was in that file, too.  It was a
(two) broken uploads that shouldn't have happened.  But hey - that's
unstable. What would it be like if unstable wouldn't make up for his
name

 I tracked one of the packages down (apt-get source helps) and found
Martin Schulze as the responsible person.  But that was quite some
days (weeks?) ago - are those package-pages still online or were your
report lagging behind?

 HTH,
Alfie
-- 
[It is] best to confuse only one issue at a time.
  -- K&R

Re: bogus maintainers?

[Gerfried Fuchs]

* Josip Rodin <[EMAIL PROTECTED]> [2002-01-03 22:31]:
> On Thu, Jan 03, 2002 at 09:28:22PM +0100, Gerfried Fuchs wrote:
>>  And to be honest - you could have tried to check the Packages file you
>> get from debian archive.
> 
> What, you want the devel/people script to check the validity of the emails
> in the Packages files?

 Sorry that you misunderstood me. I meant that the info are/were in the
Packages-File and come from there. No need to assume for the people
there might be a broken /var/lib/dpkg/available on the Webserver or a
broken script.

> I will repeat that once again: there is nothing wrong with the script. It is
> merely showing what's in the Packages files.

 That's exactly what I was trying to say ;)
Alfie
-- 
"Wer sich die Netiquette ansieht, wird feststellen, dass sie keine
Zaehne hat, nicht wie ein Joch aussieht und sich auch nicht wie eine
Knute anfuehlt." (Christoph von Nathusius in de.soc.netzkultur)

Re: Debian Press update

[Gerfried Fuchs]

* Lasse Karrainen <[EMAIL PROTECTED]> [2002-04-16 05:14]:
> User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020130

 Why doesn't that surprise me?

> Hi!   (it's my first post here)

 And hopefully your last.

> You are probably sick and tired of this topic, but ...
> IT'S A QUARTER YEAR ANNIVERSARY OF 4.2.0 RELEASE!

 Grats, you did a well job at watching the calendar.

> Time to throw some gasoline on the flames ... Branden apparently is
> incapable of releasing it.

 Nope, he isn't.  You are incapable of understanding the issue.

> So, I suggest that anyone, with enough knowledge and TIME, reading
> this, would volunteer as XFree package maintainer.

 So, start with it.

> No, I am NOT willing to prepare and release that package.

 Then shut the fuck up.  If you can't improve the situation your comment
is worth nothing but annoying people.

> I know next to nothing about Debian internals, and I don't have enough
> time either (with my other projects and a dayjob).

 Oh, now everyone let's join in a minute of silence to honor your hard
day.

> Anyway THIS IS NO REASON for me to "shut the fuck up"

 Of course it *is* one, it's the best one.  Don't beat a dead horse - it
won't notice it.

> I am just saying what other developers don't dare to say, as it might
> damage and rip apart their magic castle.

 It is damaging the motivation of *anyone* within the project, not the
magic castle, whatever that might be.

> This risk must be taken, or Debian may die anyhow.

 There is a good german quote for that: "Totgesagte leben länger" -- I
don't know the right translation of that phrase, though.

> Of course, if no-one else is capable of maintaining that package,
> Debian is in trouble.

 Why shouldn't it?  I don't see any trouble here.

> In that case I suggest hiring a paid programmer for the job (if that
> should happen, I am willing to donate).

 You are willing to pay someone to do it?  Hey, thanks!!  How much? Or
no matter what it costs?

> XF is way too essential component to be ignored like this.

 It's *you* that is ignorant.

> Anyway, no-one will volunteer as long as Branden is officially working
> on it, so I suggest that the first thing to do is getting rid of him.

 Noone is willing to do anything as long as you are spreading flamebaits
so I sugguest that the first thing to do is getting rid of you.

 You don't know next to nothing about Debian and have the nuts to feel
true enough to be able to judge it?  Boy, you have a big problem.  Feel
welcome to my blacklist.

 Have fun,
Alfie
-- 
ohne speicher, tastatur, mouse, pladde, monitor, also nur die Hardware...
  -- _DeadBull_ in #debian.de


pgpHpMlEGeM1Z.pgp
Description: PGP signature

Re: DebianWiki migrated

[Gerfried Fuchs]

Am Montag, den 16.03.2009, 21:29 +0100 schrieb Frank Lin PIAT:
> The DebianWiki team is pleased to announce that the wiki is now running
> moinmoin 1.7, which brings many new features (see [1] and [2]).

 IMHO this announcement should have gone to debian-devel-announce - but
nevertheless, thanks for the fine work. :)

 So long!
Rhonda


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: grouping of alternative depends

[Gerfried Fuchs]

* Holger Levsen  [2009-03-29 19:46:33 CEST]:
> Hi,
> 
> On Sonntag, 29. März 2009, Adeodato Simó wrote:
> > Hm? Your original mail said you wanted:
> > Depends: (pdns-backend-ldap + pdns-recursor) | bind9
> > How does installing bind9 plus pdns-backend-ldap not satisfy the above?
> 
> Sure it does satisfy the depends, but installing pdns-backup-ldap is not 
> needed in that case, thus I consider this buggy.

 If you have bind9 installed, pdns-backup-ldap won't even get
considered for installation, so there is nothing buggy here.

> > Is it relevant whether pdns-backend-ldap is installed or not once bind9
> > has been installed?
> 
> Actually our use-case is to have pdns installed on new installations and 
> bind9 
> not be removed on upgrades...

 I think that is not possible to have, at all. Unless you explicitly
depend on both pdns and bind9, but I take it that you don't want that.
:)  Maybe reducing bind9 to a Recommends would work from a transitional
point of view?

 So long,
Rhonda


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

Bug#529274: ITP: nagzilla -- jabber relay bot

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs 


* Package name: nagzilla
  Version : 1.5.4-1
  Upstream Author : Bill Mathews of Hurricane Labs
* URL : http://code.google.com/p/nagzilla/
* License : GPLv2
  Programming Lang: Perl
  Description : jabber relay bot

Nagzilla was designed to be a Jabber relay "bot", in that it sits
quietly in a room until it gets a message to relay to either a chat room
or a person. The early work was based on several simple examples out on
the Internet, but would just keep logging into a room every time the bot
had something to say. It was made a daemon, which allows it to get
Nagzilla alerts from various systems and event creators. Nagzillac (the
client program) accepts any string input and makes it into a Jabber
message. This should work with Google Talk (as it's Jabber-based), but
that is untested.

 So long. :)
Rhonda



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

Re: Who uses @packages.d.o mail?

[Gerfried Fuchs]

* Stephen Gran  [2009-05-22 23:30:03 CEST]:
> If this is actually the case, I'd like to close the domain down to only
> accept mail from other debian.org machines.  If it's not, I'd like to work
> with people who do use it to either make it possible to send their mail
> from debian.org machines or from a short whitelist of machines elsewhere.

 Not everyone has access to an debian.org machine, and
@packages.debian.org is the address used in debconf po files for
reporting messageID bugs to. A canonical easy way to reach the
maintainer(s) of a package without digging around in various fields
though is appreciated, and this is the one.

 So long,
Rhonda


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

Re: [Dctrl-tools-devel] Description-less packages file

[Gerfried Fuchs]

  Hey,

* Joerg Jaspert  [2011-11-03 22:39:02 CET]:
> I just merged a patch from Ansgar to generate the Packages files without
> the English description embedded inside them. Instead they are now
> written into a new file, the "English Translation" file in
> "main/i18n/Translation-en.bz2". They thus appear alongside all other
> translated descriptions as "just another language". apt & co will (or
> should) just download those Translation files to show the description,
> as they do already for all other languages.

 I am investigating from the packages site point of view already, this
is the case in Ubuntu for a bit already and I can use
packages.ubuntu.com as testbed for that. :)

 I hope to get this done in the not too far future.
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


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

Re: Unofficial repositories on 'debian' domains

[Gerfried Fuchs]

* Stefano Zacchiroli  [2012-03-13 09:47:43 CET]:
> Thus far, no objections have been raised on the above proposal. Also, it
> has been pointed out that past privacy concerns were related to the way
> in which the entries were published, rather than to the actual
> opportunity of doing so.
> 
> Barring other objections, I hereby propose to go ahead and publish at
> www.debian.net an automated generated lists of registered services,
> associated to the Debian login name who has registered them.

 www.debian.net is currently an alias for www.debian.org - this needs to
get entangled and a page put there to tell people clearly that anything
below debian.net is not an official representation of the Debian project
but some additional service offered by some DD.

> I'll be happy to do the non-automated documentation part, but I could
> use help (busy days ahead...) to write the scripts that query LDAP and
> generates the HTML index. Any volunteer?

 As a starting point, you can use this query, which should be parseable
easily by anything:

 ldapsearch -h db.debian.org -b ou=users,dc=debian,dc=org -x '(dnsZoneEntry=*)' 
dnsZoneEntry

 dnsZoneEntry needs to be queryable by the box on which www.debian.net
will be running, obviously.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


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

Bug#698293: ITP: nafe -- toolset for editing psf format consolefonts

[Gerfried Fuchs]

Package: wnpp
Severity: wishlist
Owner: Gerfried Fuchs 

* Package name: nafe
  Version : 0.1-1
  Upstream Author : Eric Price 
* URL : http://nafe.sourceforge.net/
* License : GPLv2
  Programming Lang: C
  Description : toolset for editing psf format consolefonts

 The package contains two tools: psf2txt and txt2psf.  With the help of these
 tools it is possible to change consolefonts in psf format.  To not lose the 
 embedded unicode character table you need the psf table tools from the 
 console-tools package, too.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


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

Re: Backports, Stable releases, Testing, Oh my!

[Gerfried Fuchs]

Hi there.

* Paul Tagliamonte  [2014-02-25 23:59:05 CET]:
> I'm sending to both -devel and backports. I'm not sure which is the
> correct list. If one's wrong, feel free to drop it in replies.
> 
> I've been talking with a mentee about backporting procedures, and I've
> explained why we don't backport until a package hits tending (stable <
> stable-bpo < testing <= unstable)

 Right, reason being to make sure (for a certain degree) that an upgrade
path from stable + bpo to next-stable without bpo is possible.

> However, with the new testing removals from the release team (which is
> totally great for creating an always releasable testing, many thanks for
> that), we can create a situation where stable-bpo has a newer version
> than testing when we release (lazy maintainer never fixed the rc bug).

 Erm, no, not at all.  A package in stable-bpo can't have a newer
version than testing when we release.  With the removal there can be two
situations:

 * After fixing the issue that got the package removed from testing, the
   package flows in like usual into testing, and it will definitely have
   at least the version it had in testing before, most probably higher,
   but never lower.

 * The package doesn't flow into testing anymore before the release.  If
   this is expected to happen, the package has to be removed from
   stable-bpo.

> What shall we do? Remove from stable-bpo? Hope an update comes around?

 Remove from stable-bpo if it's not expected to come back in is what we
actually do, yes.  And to have an overview of these situations I created
myself the diffstats page:
http://backports.debian.org/wheezy-backports/overview/

 Looking at the "not available" page, I noticed that I need to remove
the twisted-* packages.  *heading over to franck*

> Does it make sense to revisit the rules? Does a wait until testing still
> make sense (ok, waiting always makes sense, but beyond the 'let it
> settle' thing)

 Sure the wait until testing makes sense, as much as the testing
transition period in itself makes sense.  There are exeptions granted
(for security related uploads mostly), but yes, that rule does indeed
make sense.  You never know what RC might pop up that hinder the testing
transition and you are then stuck with a newer version in stable-bpo
than in testing for until the RC got fixed.

 So, no need to panic, all under control, just a bit overworked and
things not happening as timely as they should.

 Enjoy,
Rhonda
-- 
Fühlst du dich mutlos, fass endlich Mut, los  |
Fühlst du dich hilflos, geh raus und hilf, los| Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los   | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los|


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140226084755.ga19...@anguilla.debian.or.at

Re: Backports, Stable releases, Testing, Oh my!

[Gerfried Fuchs]

Hi.

* micah  [2014-02-26 16:48:45 CET]:
> Gerfried Fuchs  writes:
> >  Remove from stable-bpo if it's not expected to come back in is what we
> > actually do, yes.  And to have an overview of these situations I created
> > myself the diffstats page:
> > http://backports.debian.org/wheezy-backports/overview/
> >
> >  Looking at the "not available" page, I noticed that I need to remove
> > the twisted-* packages.  *heading over to franck*
> 
> The only reason that this one shows up to be removed is because the
> package names changed in unstable/testing from twisted-* to
> python-twisted-* so I don't think that this should be removed.

 The source packages were changed indeed after looking, but the removal
happened over a month ago.

> You might argue that a newer version from testing should be put into
> bpo and these removed, which I wont argue against, but updating the
> version in bpo From a new testing version should not be rushed due to
> this aggressive removal situation.

 I am uncertain what you call an "aggressive removal situation" here.
It happened a month ago in testing/unstable, and it was a RoQA.  Your
"aggressive removal situation" call is as unjustified as the "Oh my" in
the subject.  It would be nice if we can keep the tone civilized.

 The package doesn't exist in testing or unstable anymore since a month,
and given that we expect from backport maintainers to track the packages
they package, I would expect either an update on the situation; silence
doesn't improve the situation.

> Personally, I've found the aggressive removal from testing to be a shock
> in a number of cases.

 Then please discuss that issue with the ftp masters or release team.
As backports team we only want packages in backports which are expected
to be in the next stable release.  A package that isn't anymore in
testing/unstable for sure won't be part of the next stable release.

> I understand the motivations behind it, but it feels like a bit too
> aggressive pressure for my tastes. I've seen a lot of developers of
> packages who have found out their package will be removed from
> testing, but don't have the time to resolve the situation before it
> gets removed, resulting in much pulling of hair.

 I think you might be mixing two things up.  You are speaking about
removal from testing, but mean keeping them in unstable?  This isn't the
case here, the package was removed completely, not only from testing.

> I feel like the window for removal from testing is too short and is
> having negative consequences on the stress level of people whose
> volunteer labor contributions to Debian are already stretched thin.

 How long would be not too short for you?  A month seems to be too short
it seems.  Sorry 'bout that.

> Most everyone I've spoken to in this situation has said that it
> wouldn't be so bad if they had just a couple more days.

 A day or more doesn't make much difference after a month, does it?
Thing is, where would you draw the line then.  A month and a week?  Then
the next person would say a few more days won't hurt, and the time gets
extended endlessly.  That doesn't us get anywhere.

> I'd like it if that shock wasn't also quickly passed on to backports
> and instead things were examined a little more closely before purging
> packages. 

 Please.  "Quickly", a month?

> For example, say package X has been backported at version 1.0, version
> 2.0 is uploaded to sid, transitions to jessie and then has an RC bug
> that threatens removal. The problem with the 2.0 package has to do with
> some security issue upstream, which looks like it will be a deep code
> massage to fix and will take a while, too long for the testing removal
> auto firing squad. The maintainer wishes that they had not uploaded 2.0
> yet, because 1.0 was fine.

 This is a *completely* different situation and has nothing to do with
the twisted-* packages.  They weren't pulled from testing, they aren't
in *unstable* anymore neither.  Those packages don't exist anymore.
Yes, renaming is an unforunate situation, but even then, a month waiting
time doesn't seem to be too unreasonable, does it?

> Now backports sees the difference, because the 1.0 version has been
> removed from testing, so bpo now has a newer version than what is in
> testing. But the package is actually a *better*, but backports gets its
> package removed anyways.

 backports gets packages removed which aren't available anymore.  This
hasn't changed at all, it's nothing new, it happened in the past.

> Maintainer decides to eat the epoch and re-uploads version 1.0 to get a
> functioning package, uploads urgency high and package transitions to
>