Re: Why does Salsa use reCAPTCHA?

[Alexander Wirt]

On Thu, Sep 12, 2024 at 12:13:50AM +0200, Preuße, Hilmar wrote:
> Am 06.09.2024 um 18:30 schrieb Ceppo:
> 
> Hi,
> 
> > I see that Salsa requires reCAPTCHA resolution to sign up, and it
> > also embeds reCAPTCHA code in most or all pages - or at least so it
> > looks to me as an absolute Javascript ignorant.
> > 
> When looking at my QA page [1] I currently notice that vcswatch runs into a
> "401 Unauthorized at /srv/qa.debian.org/data/vcswatch/vcswatch" for all
> salsa based projects.
> 
> I guess here is a correlation.
I guess thats just wrong. I would guess for an expired token. Tokens in
general don't need captcha. 

Alex



signature.asc
Description: PGP signature

Debian Weekly News Letter RSS Feed

[Alexander Wirt]

Hi guys,
I found some time to set up a rss feed for the dwn, try:
http://people.debian.org/~formorer/dwn/dwd.rss
Have fun
Alex

Re: Debian Weekly News Letter RSS Feed

[Alexander Wirt]

Peter Hoffmann wrote:
Alexander Wirt wrote:
Hi guys,
I found some time to set up a rss feed for the dwn, try:
http://people.debian.org/~formorer/dwn/dwd.rss
Great work.
But your link has a typo. Try this one:
http://people.debian.org/~formorer/dwn/dwn.rss
Args... You are of course right :).
Much too early in the morning.
Thanks
Alex

Re: Bug #277824; is the hotkeys maintainer dead?

[Alexander Wirt]

Jeroen van Wolffelaar wrote:
On Sun, Dec 05, 2004 at 09:39:42PM -0500, Thomas Folz-Donahue wrote:
Where is Anthony Wong?

Please see http://bugs.debian.org/280817 -- it's in need of a new
maintainer.
Since I use hotkeys every day and did some work on it before the woody 
release I will take the package. Unfortunatly I'm currently moving and
my office isn't fully restored yet it will take a week or two until the
upload. If somebody needs the package earlier he should give me a short
mail and do an upload on his own.

sincerly
Alex

Bug#303891: ITP: gcfilms -- a GTK2 application for managing dvd and video collections

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

* Package name: gcfilms
  Version : 4.8
  Upstream Author : Tian <[EMAIL PROTECTED]>
* URL : https://gna.org/projects/gcfilms/
* License : GPL
  Description : a GTK2 application for managing dvd and video collections

gcfilms is a program for managing dvd and video collections. 
It 
 * retrieves and display movie informations from severeal 
   online sources like amazon or imdb
 * can import movie informations from Ant oder DVD Profiler collections
 * can export movie informations to CSV, HTML, SQL or XML
 * has a flexible plugin system for export, import or search plugins
 * has a borrower system to track where are movies are


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9-1-k7
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Ubuntu and its "appropriation" of Debian maintainers

[Alexander Wirt]

Hi Matt!

On Sun, 01 May 2005, Matt Zimmerman wrote:

> On Sun, May 01, 2005 at 09:36:57PM +0200, Andreas Barth wrote:
> 
> > Actually, I don't think that the packages.*-code is part of the problem.
> > Ubuntu treats the Debian maintainers at many places as "their"
> > maintainers, e.g. at apt-cache show $package. The packages.*-code just
> > displays that wrong information.
> 
> [Note that this is an entirely different matter from the one mentioned in the
> original post]
> 
> Every Debian derivative I have seen does this the same way.  There is some
> inaccuracy in either case, but I think this is the lesser of the evils:
> 
> - Changing the maintainer field
>   - " is taking credit for my work!"
>   - Requires modification of every source package, even if it is otherwise
> identical
If they change anything - this includes branding stuff too - the should 
change the maintainer field. If the package is identical to the debian one
it could stay as it is.

Just my 2 cents 

Alex


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

Re: Hosting for DebBlue (Set of themes for Debian)

[Alexander Wirt]

Jaap Haitsma schrieb am Samstag, den 28. Mai 2005:

> Hi,
*snip*
> Is there somebody else who can help me out. The website needs about 15MB 
> of space and needs PHP.
No problem I have enough webspace and also php4, so send me a mail if you are
interested. 

Best wishes
Alex


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

Re: Packaging of freenx

[Alexander Wirt]

Tollef Fog Heen schrieb am Dienstag, den 07. Juni 2005:

> * "Roberto C. Sanchez" 
> 
> | On Tue, Jun 07, 2005 at 04:27:58PM +0200, Fabio Tranchitella wrote:
> | > On Tue, 07 Jun 2005 at 10:16 -0400, Roberto C. Sanchez wrote:
> | > > I asked a while back (on IRC) about packaging the NX components that are
> | > > under the GPL.  Someone pointed me to Fabian's packages in Skole Linux.
> | > > Anyhow, those packages are 6 months old and probably not going into
> | > > Debian.  Fabian has also not responded to my email.
> | > 
> | > See #255850, maybe it could give you some information.
> | 
> | OK.  No activity in more than a year.  The website where the packages
> | were offered early in the thread no longer exists.
> | 
> | If there are no objections, I will take over the ITP.
> 
> I talked with Stefan Lippers-Hollmann a few days ago about it and
> apart from some technical problems with it (namely that the NX build
> system is an interesting case of «let's see how messed-up we can make
> this build» and no development package), it's almost ready to go into
> sid.
> 
> I've offered to sponsor him if he needs that and would be interested
> in helping out with packaging.  Note that there's a pkg-nx repository
> on alioth too, even though it hasn't been used for anything yet.
yeah, I offered to sponsor them a year ago and created the repo. I planned to
hijack the ITP in the next days to get freenx into debian. 
But I'm also happy to Co-Maintain the package. I'm the admin of the pkg-nx
repo, so I'm able to give access to everybody who is interested.

Best whishes
Alex

Re: Packaging of freenx

[Alexander Wirt]

Andreas Tille schrieb am Mittwoch, den 08. Juni 2005:

> On Wed, 8 Jun 2005, Alexander Wirt wrote:
> 
> >yeah, I offered to sponsor them a year ago and created the repo. I planned 
> >to
> >hijack the ITP in the next days to get freenx into debian.
> >But I'm also happy to Co-Maintain the package. I'm the admin of the pkg-nx
> >repo, so I'm able to give access to everybody who is interested.
> So there are obviousely so many people who are interested that my first
> step would be to create a mailing list for this project and subscribe
> all parties if I would be in your shoes.
Good Idea. Here we are: I created [EMAIL PROTECTED], it
will take a few hours until the list will be functional. 

Everybody who wants to participate in the freenx packaging should join there. 

Best wishes
Alex


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

Re: Packaging of freenx

[Alexander Wirt]

Roberto C. Sanchez schrieb am Mittwoch, den 08. Juni 2005:

> [offlist] 
> 
> On Wed, Jun 08, 2005 at 10:25:23AM +0200, Alexander Wirt wrote:
> > yeah, I offered to sponsor them a year ago and created the repo. I planned 
> > to
> > hijack the ITP in the next days to get freenx into debian. 
> > But I'm also happy to Co-Maintain the package. I'm the admin of the pkg-nx
> > repo, so I'm able to give access to everybody who is interested.
> > 
> 
> If you could grant me access, I would appreciate it.  My Alioth username
> is el_cubano-guest.
You have been added, please join the mailinglist and start with us how the
packaging will be done in the future. 

best wishes 
Alex

Bug#392119: ITP: php-suhosin -- security extension for php

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

  Package name: php-suhosin
  Version : 0.9.8
  Upstream Author : Stefan Esser <[EMAIL PROTECTED]>
  URL : http://www.hardened-php.net/suhosin.127.html
  License : PHP License 
  Programming Lang: C
  Description : security extension for php

 Suhosin is an advanced protection system for PHP installations. It was
 designed to protect servers and users from known and unknown flaws in PHP
 applications and the PHP core. Suhosin comes in two independent parts, that
 can be used separately or in combination. The first part is a small patch
 against the PHP core, that implements a few low-level protections against
 bufferoverflows or format string vulnerabilities and the second part is a
 powerful PHP extension that implements all the other protections.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (200, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc5
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: exim configuration in master, and per-user DNSBLs

[Alexander Wirt]

Santiago Vila schrieb am Mittwoch, den 13. Dezember 2006:

 
> While we are at it, allowing each user to choose among several popular
> DNSBLs would be great too. In fact, there is a dnslists file in /etc/exim4
> which already contains several role accounts (and at least one which is not).
> We would just need to modify db.debian.org slightly so that such file
> is generated automatically from email preferences in our LDAP database.
No, please don't do this. Using _one_ rbl to decide if to reject a mail ist
broken. You should never rely on one external source for deciding if you
should accept a mail. I would consider every system broken that works like
this. It would be ok to ask >= 3 lists and to reject if all or most of them
listed the ip.

Alex


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

Re: exim configuration in master, and per-user DNSBLs

[Alexander Wirt]

Santiago Vila schrieb am Freitag, den 15. Dezember 2006:

> On Fri, 15 Dec 2006, Alexander Wirt wrote:
> 
> > Santiago Vila schrieb am Mittwoch, den 13. Dezember 2006:
> > 
> > > While we are at it, allowing each user to choose among several popular
> > > DNSBLs would be great too. In fact, there is a dnslists file in /etc/exim4
> > > which already contains several role accounts (and at least one which is 
> > > not).
> > > We would just need to modify db.debian.org slightly so that such file
> > > is generated automatically from email preferences in our LDAP database.
> >
> > No, please don't do this. Using _one_ rbl to decide if to reject a mail ist
> > broken. You should never rely on one external source for deciding if you
> > should accept a mail. I would consider every system broken that works like
> > this. It would be ok to ask >= 3 lists and to reject if all or most of them
> > listed the ip.
> 
> Please *login* to master.debian.org and *read* /etc/exim4/dnslists.
> 
> Five role accounts and another one which is not a role account are
> already using a "single" DNSBL, namely sbl-xbl.spamhaus.org.
> 
> I think we, common developers, should also have the freedom to use
> sbl-xbl or not. If I chose to do so, it would be for *my* email, not
> for *yours*, so please don't try to tell me what it's ok or what
> it's not. Receiving more than 100 spams a day certainly is not.
Then I consider it double broken, spamhaus ist not an acceptable list. And
its not ok to block against a single list. 

Alex


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

Bug#403862: ITP: pdfcube -- PDF presentation programm with eyecandy 3D effects

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

* Package name: pdfcube
  Version : 0.0.2
  Upstream Author : Mirko Maischberger <[EMAIL PROTECTED]>
* URL : http://code.100allora.it/pdfcube/wiki
* License : GPL
  Programming Lang: C++
  Description : PDF presentation programm with eyecandy 3D effects

PDFCube renders PDF presentations with special 3D effects (the
omnipresent rotating cube and 5 predefined zoom animations). It adds
eye-candy to your PDF presentations, even Latex, Beamer and Prosper
ones.

 (The description will probably improved later) 

-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (200, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-rc5
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: Bug#403862: ITP: pdfcube -- PDF presentation programm with eyecandy 3D effects

[Alexander Wirt]

Joachim Breitner schrieb am Mittwoch, den 20. Dezember 2006:

*snip*

> Interesting. It seems to be similar to keyjnote. Does it support
> clicking on internal links of the pdf document, or is it just rendering
> the pdf as ???dumb images??? on the screen?
It looks like that they are just rendered as images, but pdfcube is in a very
early stage, so hopefully this will change. 

> Maybe there should be a shared library of 3D transitions effects that
> can be used by pdfcube, keyjnote, xscreensaver, compiz...
Interesting idea, this should improve the quality of all 3D transitions used
by them...

Alex


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

Bug#360285: ITP: libjoey -- forks itself and does several things at the same time

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

* Package name: libjoey
  Version : 0.1.4
  Upstream Author : Martin 'Joey' Schulze
* URL : http://www.infodrom.org/
* License : GPL
  Description : forks itself and does several things at the same time

libjoey is a opensource fork of the famous Martin 'Joey' Schulze, this
library magically forks itself and does several important things at the
same time. With linking against libjoey you are able to make you
applications do more things at the same time. 
It will be uploaded as soon as I'm able to catch Joey and put him in a
box. 


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-1-amd64-k8
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) (ignored: 
LC_ALL set to [EMAIL PROTECTED])


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

Re: Sun Java available from non-free

[Alexander Wirt]

Anthony Towns schrieb am Donnerstag, den 18. Mai 2006:

> On Wed, May 17, 2006 at 11:09:30PM -0700, Don Armstrong wrote:
> > First off, I'm going to completely ignore the FAQ as the FAQ and the
> > license both specifies that the FAQ does not have any legal validity.
> 
> Repeating frequently asked questions that have already been answered
> isn't terribly useful.
This is not the way a DPL should answer, we were asking important questions
and its our right to get sane answers. 

> 
> > As a final note, did anyone from Debian who usually examines licences
> > actually examine this one? 
> 
> Yes. 
I give nothing about an analysis I haven't seen from somebody I dont know. 
Uploading such a package with such a license without any discussion is a
shame for Debian. Some not mentioned ftp-master waved the package (as the
only package) through after a few hours, beside that this ftp-master didn't
processed NEW for a long time. This all really smells strong and after
reading the license carefully and talked with several other people I came to
the conclusion that I have to do anything that I can to get this out of
debian again. This is not the freedom I'm standing for. And after all thats
not the way I wanted a project I'm working in to act, I see this way of
acting as a personal affront to me and my Debian work... 

This really went wrong and I want to have some _good_ explanations or we will
have to bear the consequences. 

Alex


signature.asc
Description: Digital signature

Re: Sun Java available from non-free

[Alexander Wirt]

Raphael Hertzog schrieb am Sonntag, den 21. Mai 2006:

 
> PS: Yeah I'm a bit pissed of that we only have people criticizing when we
> do great things.
You can get applause if you do great things, not if you do harm to debian and
opensource. 
As I said, the license has to be changed. 
 
Alex


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

Re: Sun Java available from non-free

[Alexander Wirt]

Raphael Hertzog schrieb am Sonntag, den 21. Mai 2006:

*snip*

> The license is good enough for Debian (ftpmasters took their decisions).
> There's no fix to require, but it would be good to continue working them
> to enhance even more the license. Such a constructive behaviour would put
> us in a good position to make sure that Sun releases java in a DFSG-free
> compliant license when they will open-source it.
I strongly disagree, did you ever red the licence?
And even a ftp-master decision can be wrong. Or it can be overriden by the
project via a GR (a way that I'll go if I have to)

Alex


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

Re: Bug#290652: ITP: kernel-patch-ibookg4-suspend -- patch to support for hibernation in new G4 ibooks

[Alexander Wirt]

Jorge Bernal wrote:
Package: wnpp
Severity: wishlist
* Package name: kernel-patch-ibookg4-suspend
  Version : test6
  Upstream Author : Benjamin Herrenschmidt <[EMAIL PROTECTED]>
* URL : http://gate.crashing.org/
* License : GPL
  Description : patch to support for hibernation in new G4 ibooks
 This patch adds support for hibernation in new G4 ibooks.
 .
 Note that it's an EXPERIMENTAL patch and may not work.
 I have packages available at:
http://www.amedias.org/~koke/debian/unstable/
 There is a test7 version but does not work very well, at
 least with my ibook.
Ehm, the Test7 works fine and nobody yet complaint about it.
If you have problems please report them on debian-powerpc, I haven't
found any mail from you on this list.
Additionally the name is not chosen very good since the patch is for 
powerbooks too.

You should really get more experience with the patch if you want to 
package it. Maybe you want to try my ppc kernel packages at:
http://people.debian.org/~formorer/ppc. The packages have been reported
as working fine for ibooks.

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

Re: maildirmake

[Alexander Wirt]

Am Die, 2003-06-24 um 03.46 schrieb Matthew Palmer:
> On Tue, 24 Jun 2003 [EMAIL PROTECTED] wrote:
> 
> > Now I'm wondering about it even more.  IMHO `maildirmake' is _very_
> > necessary for any mail and as it seems to be only a 2-line-shell-script
> > why it isn't included anywhere and anyway in the base-system?
> 
> As I recall, maildirmake is only needed if you are running Maildir-based
> MDAs, which Debian does not by default[1].  That is enough of a reason not
> to ship it in the base system, regardless of whether it's a two line shell
> script or not.
I use offlineimap to get my remote IMAP Folders synced with my laptop. 
Offlineimap writes directly to maildirs. So I think there _are_ cases
where no courier is needed, but a maildirmake program. 

I installed another package thats comes with a maildirmake program, but
a real maildirmake package would be nicer ;), maybe a maildir toolbox or
something like that would be usefull.  

*snip* 

formorer

-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#319711: RFH: gtkpod -- manage songs and playlists on an Apple iPod

[Alexander Wirt]

Frank Lichtenheld schrieb am Sonntag, den 24. Juli 2005:

> Package: wnpp
> Severity: normal
> 
> I'm searching a co-maintainer for this package since it has very
> frequent upstream releases and people are eager to get them as
> quick as possible (especially when Apple released a new firmware version...),
> so I think it would be feasible to have someone I can share the load with.
As I wanted to hijack this package for myself some time ago, I would be happy
to assist you with gtkpod. 
So if you need my help, just drop me a mail :)

Best wishes
Alex


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

Re: problem installing libmotif-dev on debian sarge stable

[Alexander Wirt]

Frederico Rodrigues Abraham schrieb am Dienstag, den 26. Juli 2005:

> Hi. I am trying to install the development files for motif but i get this:
[..]

Welcome to unstable and the c++ and x.org transition. You have to wait until
the transiton is finished or fix the correspondent packages on your own.

Remember: thats the reason why its called unstable (or maybe even testing).
This could happen all the time.

Regards 
Alex


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

Re: problem installing libmotif-dev on debian sarge stable

[Alexander Wirt]

Frederico Rodrigues Abraham schrieb am Mittwoch, den 27. Juli 2005:

> i am using debian stable... (sarge)
Then I'm sorry, I tried to reproduce the problem, here my results on a fresh
installed sarge chroot:

[EMAIL PROTECTED]:/# apt-get install libmotif-dev
Reading Package Lists... Done
Building Dependency Tree... Done
Package libmotif-dev is not available, but is referred to by another 
package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  lesstif2-dev lesstif-dev
E: Package libmotif-dev has no installation candidate
Okay no problem, then we could use:

[EMAIL PROTECTED]:/# apt-get install lesstif2-dev
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
[]

Works no problem. And for completeness my sources.list:
[EMAIL PROTECTED]:/# cat /etc/apt/sources.list 
deb http://ftp.de.debian.org/debian/ sarge main
deb-src http://ftp.de.debian.org/debian/ sarge main
deb http://security.debian.org/ sarge/updates main

So you should really check your sources list and if you really have a sarge
system and not sid/etch.

Best wishes 
Alex


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

Re: problem installing libmotif-dev on debian sarge stable

[Alexander Wirt]

Andrew Vaughan schrieb am Donnerstag, den 28. Juli 2005:

[...]
> libmotif-dev is in non-free.

So what: 
[EMAIL PROTECTED]:/# apt-get install libmotif-dev 
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed
[...]

Still works

Best wishes Alex


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

Re: Bug#329462: general: standard value $LANG="[EMAIL PROTECTED]" -> very tiny GTK1 font

[Alexander Wirt]

Annett Fritz schrieb am Donnerstag, den 22. September 2005:

> Package: general
> Severity: grave
> Tags: l10n
> Justification: renders package unusable
> 
> The standard value $LANG="[EMAIL PROTECTED]" breaks fontsize for some gtk1
> programs like gxedit or tipptrainer. With $LANG="de_DE" they show a
> readable font. 
> A normal user doesn't know that when he chooses the locale
> "dpkg-reconfigure locales" during installation.
The solution would be to install the transcoded fonts by default. That fixes
that problem. 

Best wishes
Alex


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

Re: PHP License for PEAR packages

[Alexander Wirt]

Petter Reinholdtsen schrieb am Dienstag, den 04. Oktober 2005:

> [Joerg Jaspert]
> > Another pointer:
> > http://lists.debian.org/debian-legal/2005/08/msg00128.html
> 
+snip+
> So perhaps the license is free according to DFSG?
Of course its free. But it only fits to php itself. If you wan't to use it
with php as it is, it just won't fit to the pear module, which leads to a
point where the code have no license, because the php couldn't be adapted to
that code, which makes the code undistributable. Not non-free, but
non-distributable. Moving the non-free wouldn't be suitable, it has to be
removed from debian. 

As Jörg stated in his reject mail: "The reason for this decision is the
license which does not really fit the package.". Not: this license is
non-free!

Best wishes
Alex

P.S. forgive me if I'm wrong here, I'm no lawyer :)

Bug#335018: ITP: OpenVPN-Admin -- Administration and certificate manager for OpenVPN

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

* Package name: OpenVPN-Admin
  Version : 1.1.3
  Upstream Author : Everaldo Canuto <[EMAIL PROTECTED]>
Reiner Jung <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/openvpnadmin/
* License : LGPL
  Description : Administration and certificate manager for OpenVPN

An administration GUI for OpenVPN. Included is a manager and wizard for
certificates.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)



signature.asc
Description: Digital signature

New iproute in unstable

[Alexander Wirt]

Hi folks, 

its a long long time ago that iproute2 got an upstream update. I took over
the package from Andreas and decided to try a new upstream version. As I
don't want to break other peoples networking it has been uploaded to
experimental. I would be very happy if some people would give
iproute-20051007 a try and give me some feedback. 

Have fun 
Alex



signature.asc
Description: Digital signature

Re: New iproute in unstable

[Alexander Wirt]

Alexander Wirt schrieb am Samstag, den 12. November 2005:

Uhm its too late... The subject is of course misleading, it has been uploaded
to experimental. 

Alex




signature.asc
Description: Digital signature

Re: Intend to hijack rrdtool

[Alexander Wirt]

Bernd Zeimetz schrieb am Monday, den 18. February 2008:

> 
> > Do you prefer your git, or the Debian SVN or maybe git.debian.org?
> 
> I think using alioth's services would be the best way to go. We'd prefer
> git, but svn is fine, too. What's your favourite?
I'm against a move. It took me some work to get everything working and I
really would hate it if the work was useless. 

Alex
 


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

Re: Service stopping in prerm considered harmful

[Alexander Wirt]

Pierre THIERRY schrieb am Sunday, den 23. March 2008:

> For the nth time, I have a package that dpkg is unable to remove because
> it tries to stop a service that either is already stopped (I didn't want
> it) or couldn't start at all. In the former case, the fix seems simple:
> start the service and remove the package. But sometimes starting the
> service may have undesirable outcomes on the system, or the stop action
> will fail in some way.
> 
> In either case, when you can't get a successful stop action for the
> service init.d script, the package is impossible to remove without human
> action, and not a simple one, because you need to be able to hack the
> maintainer scripts or the init.d script.
> 
> Shouldn't the maintainer script actually ensure that the service is not
> running, instead of just triggering the stop action and checking its
> exit code? Something like (it's pseudo-code, because the status action
> of init.d scripts prints text, it doesn't seem to give machine-friendly
> data):
> 
> 
> # if it's running, stop it
> if(status(service) == running) {
>   stop(service);
> }
> # if now it's still running, something's wrong
> if(status(service) == running) {
>   exit 1;
> }
> # proceed...
> 
There is a small trick with dh_installinit that can be used. dh_installinit
supports an errorhandler. If called like: 

dh_installinit -i --error-handler=init_failed --init-script=amavis -- defaults 
19 21

it generates the following debhelper code for prerm and postinst:
...
invoke-rc.d amavis stop || init_failed 

All you need then is a small function like in your postinst: 

init_failed () 
{
echo "WARNING: Starting amavisd-new failed. Please check your
configuration."
}


This works fine for me and removes the annoying default behaviour of
dh_installinit. 

Alex


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

Re: Service stopping in prerm considered harmful

[Alexander Wirt]

Russ Allbery schrieb am Sunday, den 23. March 2008:

> Alexander Wirt <[EMAIL PROTECTED]> writes:
> 
> > There is a small trick with dh_installinit that can be used. dh_installinit
> > supports an errorhandler. If called like: 
> >
> > dh_installinit -i --error-handler=init_failed --init-script=amavis -- 
> > defaults 19 21
> >
> > it generates the following debhelper code for prerm and postinst:
> > ...
> > invoke-rc.d amavis stop || init_failed 
> >
> > All you need then is a small function like in your postinst: 
> 
> But if you can modify the postinst, you could just fix the init script
> (Although you may still need this for a transition.)
True, but this does not only apply to stopping the initscript but also to
package installations that stop because the daemon is unconfigured or if
something has to be changed in the configs for a new version. I find it
really annoying if a daemon that can't be started stops my installation
process. 

Alex
 


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

Re: Misc development news (#6)

[Alexander Wirt]

Raphael Hertzog schrieb am Tuesday, den 15. April 2008:

Hi,

*snip* 
> Use a recent devscripts
> ---
> 
>  With the introduction of the new Checksums-* fields in the changes file,
>  debsign had to be fixed to also update the checksums in the new fields
>  (see #474949). Be sure to run devscripts 2.10.25 or newer, otherwise
>  you'll generate broken *.changes files which will be rejected by dak.
> 
>  The current version of mergechanges is also behaving badly with those new
>  fields, it will be fixed in the next version of devscripts (2.10.26).
Aren't the dpkg maintainers able to get such things fixed in advance of
uploading dpkg? I'm still missing an announcement (of course before the
upload) about that "feature". I don't think that such an important package as
dpkg should be handled like this. 
 
*snip*

> dpkg-buildpackage sets default value to CFLAGS, etc.
> 
> 
>  Since dpkg 1.14.17, dpkg-buildpackage will define the environment
>  variables CFLAGS, CXXFLAGS, CPPFLAGS, LDFLAGS and FFLAGS. The goal is to
>  be able to easily recompile packages with supplementary compilation flags
>  and to simplify the debian/rules files since CFLAGS has the right default
>  value (no need to special case for DEB_BUILD_OPTIONS=noopt).
At first I thought: WTF? Why are such important changes to the build
enviroment not announced and discussed before they are introduced? This - in
my eyes really bad feature - produces many FTBFS, unreproducible builds and
other problems. I think it's a bad idea and it would have been nice to have it
discussed before the upload to unstable (I really hope I didn't miss an
announcement via dda). Additionally it's really really bad timing. Why does
such things have to happen when we are preparing the release? 

Again I don't think that a package like dpkg should be handled like this. 

Alex


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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository

[Alexander Wirt]

Robert Millan schrieb am Saturday, den 21. June 2008:

> reopen 480478
> retitle 480478 ITP: debian-backports-keyring -- GnuPG archive key of the 
> backports.org repository
> reassign 480478 wnpp
> thanks
> 
> * Package name: debian-backports-keyring
> * URL : 
> http://backports.org/debian/pool/main/d/debian-backports-keyring/
> * License : GPLv2+
>   Description : GnuPG archive key of the backports.org repository
> 
> Alexander, please let me know if you have any objection to this key being
> added to the archive, or if you would like to be the maintainer for this
> package or just the upstream (either way is fine with me).
I'm still not that sure if its a good idea to add a non-offical debian repo
keyring into the archive... But I let the decision to the ftp-masters..

Alex


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

Re: Spam on the lists [Was: Re: Account Upgrade (Unex)]

[Alexander Wirt]

Christian Perrier schrieb am Tuesday, den 04. August 2009:

Hi,  
> > > look it up yourself:
> > > http://lists.debian.org/archive-spam-removals/review/stats.html (my
> > > user is morph...). So, are you going to help us kill spam (reporting
> > > it) or no time for this?
> > 
> > So you're Debian's Mr. Antispam, my humble apologies.  
> 
> 
> .../...
> 
> What's interesting to add is that I've heard at Debconf that the
> identified (and removed) spam is now used to feed out CRM114 on
> lists.d.o (or will be, I'm not sure). So, the more spam filtering is
> done...the better our spam filters might become.
It will be in the future. I'm currently evaluating CRM114 together with
amavisd-new on a private setup. Next step will be updating my lists.d.o
amavis packages and after that we will run crm114 with a low scoring. 
If everything works well a few weeks later crm114 should replace the old
bayes.

Alex - listmaster


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

hijacking asciidoc - [EMAIL PROTECTED] MIA?

[Alexander Wirt]

Hi, 

asciidoc is currently in a bad shape and pretty outdated, as I use
asciidoc regulary I'm very interested in having a new and good
maintained asciidoc package. Unfortunatly there are bugs like #376523
which are really annoying and easy to fix. The maintainer also seems to
be very inactive, according to MIA his last activity was in october 2006
which is a little bit ago. Frederik - if you need any help or
co-maintenance just tell me, but I didn't received an answer of my last
mail. So if there are no objections I would hijack asciidoc in a few
days, but I would prefer to get a lifesign of the real maintainer :). 

Best wishes

Alex



signature.asc
Description: Digital signature

Re: [EMAIL PROTECTED], [EMAIL PROTECTED]

[Alexander Wirt]

Manoj Srivastava schrieb am Samstag, den 12. Mai 2007:

Hi Manoj, 

> I would like to backport SELinux related packages to Etch, and
>  thus would like to get my key into the backports key ring.What do I
>  need to do to enable that?
Use the website, 
use the mailinglist. 

But why do you use -devel? Backports.org has nothing to do with debian-devel. 
And maybe it would be usefull to have one of us, or even both in CC.

I added your key. 

Alex


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

Re: [EMAIL PROTECTED], [EMAIL PROTECTED]

[Alexander Wirt]

Alexander Wirt schrieb am Samstag, den 12. Mai 2007:

> Manoj Srivastava schrieb am Samstag, den 12. Mai 2007:
> 
> Hi Manoj, 
> 
> > I would like to backport SELinux related packages to Etch, and
> >  thus would like to get my key into the backports key ring.What do I
> >  need to do to enable that?
> Use the website, 
> use the mailinglist. 
> 
> But why do you use -devel? Backports.org has nothing to do with debian-devel. 
> And maybe it would be usefull to have one of us, or even both in CC.
> 
> I added your key. 
I missed something: 
please subscribe to our users mailinglist:
http://lists.backports.org/mailman/listinfo/backports-users

Thanks

Alex



signature.asc
Description: Digital signature

Bug#424842: ITP: docbook2odf -- XSLT based conversions from docbook to Oasis Open Document (openoffice.org)

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt <[EMAIL PROTECTED]>

* Package name: docbook2odf
  Version : 0.211
  Upstream Author : Roman Fordinal
* URL : http://open.comsultia.com/docbook2odf/
* License : GPL
  Programming Lang: Perl
  Description : XSLT based conversions from docbook to Oasis Open Document 
(openoffice.org)

toolkit that automaticaly converts DocBook to OASIS OpenDocument
(ODF, the ISO standardized format used for texts, spreadsheets and
presentations).  Conversion is based on a XSLT which makes it easy
to convert DocBook->ODF, ODT, ODS and ODP as all these documents are
XML based.

Alex

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (200, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.21.1
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash


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

Re: APT 0.7 for sid

[Alexander Wirt]

Michael Vogt schrieb am Montag, den 11. Juni 2007:

Hi, 

*snip*
> [..]
> > - automatic installation of recommends like aptitude
> [..]
> 
> This is currently turned off because of the concerns raised. its a
> matter of changing the default of "APT::Install-Recommends" to true. 
> 
> I want to turn it on by default in the near future, but with a
> reasonable warning time for the transition.
Please never make it a default. Humans make errors and I never want packages
installed by default. I consider this really a dangerous option (but maybe
usefull on desktops) so just integrate some kind of button in synaptic & co,
but please don't make it a default.

Alex
 


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

Re: APT 0.7 for sid

[Alexander Wirt]

Raphael Hertzog schrieb am Montag, den 11. Juni 2007:

> On Mon, 11 Jun 2007, Alexander Wirt wrote:
> > > I want to turn it on by default in the near future, but with a
> > > reasonable warning time for the transition.
> > Please never make it a default. Humans make errors and I never want packages
> > installed by default. I consider this really a dangerous option (but maybe
> > usefull on desktops) so just integrate some kind of button in synaptic & co,
> > but please don't make it a default.
> 
> I disagree. Please make it the default. We need consistency and that's the
> intended meaning of that field.
> 
> You really need to explain why it would be a dangerous option when the
> only problem could be that the user has installed more packages than
> really needed. Otherwise your disagreement is of no value.
Args it was too early in the morning. Please forget my mail. I was at the
"install security updates automatically feature". Sorry the he mess. 

Alex
 


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

Bug#496967: general: System completely blocks any input

[Alexander Wirt]

Frank Küster schrieb am Saturday, den 30. August 2008:

Hi, 

*snip*
> Is there any live system available which can handle lvm volumes? I think 
> I even have some free disk space for an additional partition to install 
> the live system on harddisk. But I cannot access it from Knoppix, and 
> didn't find information on lvm in the Knoppix FAQ.
grml [1] has support for lvm. Just start it via /etc/init.d/lvm start after
booting. 

Alex

[1] http://www.grml.org/




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

Re: pkg-netfilter team (was: Re: Bug#502402: ITP: xtables-addons -- Extensions for iptables)

[Alexander Wirt]

Faidon Liambotis schrieb am Wednesday, den 29. October 2008:

> Max Kellermann wrote:
> >> What do you all think?
> > 
> > +1 from me.  We are already maintaining our packages in a (private)
> > subversion repository which we could (and should) move to Alioth.  Of
> > course it's a good idea to have a bigger team, since I am an
> > unofficial Debian maintainer, and sometimes Alexander doesn't have
> > enough time to sponsor my package uploads, leading to unnecessary
> > delays.
> Thanks for this!
> 
> I created an alioth project with the name of "pkg-netfilter".
> Please apply for membership:
>   https://alioth.debian.org/projects/pkg-netfilter/
> 
> Please discuss with Alexander if and how we can move your private
> repository to Alioth. I guess an svndump would be a good starting point.
I never said I want to move to alioth. 

> 
> We should do this now, merging repositories at a later step would be far
> more difficult.
> 
> Also, I haven't heard back from the other maintainers (still Cc'ed) but
> I guess we have enough packages for a packaging team to exist.
> Still, it'd be nice to have a larger team.
> 
> Thanks,
> Faidon


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

Re: Backports now appearing on debian.org package listings?

[Alexander Wirt]

Tim Hull schrieb am Sonntag, den 02. September 2007:

Hi Tim,

> Does this mean anything with regards to how backports will operate?  I'm
> just curious, as you probably know from my past posts that I'm quite
> interested in stable release updates beyond simple security updates...
Speaking as a backports.org ftp-master nothing changed and will
probably not in the near future.

Alex



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

amavisd-new 2.5.2-1 uploaded to experimental

[Alexander Wirt]

Hi folks, 

after some work I uploaded amavisd-new 2.5.2-1 to experimental. I plan to
upload it to unstable as soon as possible, so please test it carefully. 

Here the changelog: 

 amavisd-new (1:2.5.2-1) experimental; urgency=low
 .
   * New upstream release (Closes: #427337, #434533)
   * Don't remove the amavisd user (Closes: #431853)
   * Fix unix socket path in /etc/amavis/conf.d/25-amavis_helpers
 (Closes: #406998)
   * Disable non-free unpackers (Closes: #410588)
   * Add myself to uploaders
   * Instead of interrupting the upgrade process if starting/stopping
 amavisd-new just warn (Closes: #430028)
   * Add suggestion to dspam (Closes: #423737)
   * Add dutch po files (Closes: #413886)
   * Add galician po file (Closes: #413459)
   * Fix typos in debian configs (Closes: #414421)
   * Fix comment for the X_HEADER_LINE option (Closes: #433268)
   * Conflict against older versions of logcheck since we track logcheck files
 now.
   * Update logcheck rules (Closes: #406613, #406854, #409053)

The conflict against logcheck will be solved in a coordinated upload of
logcheck and amavisd to unstable. 

Thanks in advance 

Alex

-- 
Alexander Wirt, [EMAIL PROTECTED] 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A


signature.asc
Description: Digital signature

Re: Apparent portmap to rpcbind transition?

[Alexander Wirt]

Mark Brown schrieb am Donnerstag, den 07. Januar 2010:

Hi, 

> > I see that nfs-common depends on portmap | rpcbind. However, nis only 
> > depends
> > on portmap, and can therefore not be installed at the same time as rpcbind.
> 
> Yes, this is the root of the issue - if we're changing what we're doing
> with portmappers what's the plan for managing this.  What should be the
> default, is the old portmap going away and so on.  At the minute there's
> been no coordination at all, the first time I heard of rpcbind was when
> I was resolving the NFS breakage.
Ehm, the reason was a bug. nfs-common was broken, if connecting to localhost
it was only trying ::1, but without a fallback on 127.0.0.1.

There wasn't any indication in the package that this breakage was on purpose. 
I guess it was just bad testing. 

The NMU is in delayed/1 and should hit unstable in a few hours. 

Alex


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

Re: Misc developer news (#21)

[Alexander Wirt]

Mike Hommey schrieb am Saturday, den 20. February 2010:

> On Sat, Feb 20, 2010 at 09:03:10AM +0100, Marc Haber wrote:
> > On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog
> >  wrote:
> > >On Fri, 19 Feb 2010, Marc Haber wrote:
> > >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote:
> > >> >   * More than 1000 source packages[4] are already using the new source
> > >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your own
> > >> > packages already?
> > >> 
> > >> Why should I?
> > >
> > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F
> > 
> > I don't see any valid reason to convert packages which already use a
> > patch system such as dpatch to the new thing. Debian is in dire need
> > of manpower taking care of our core infrastructure, converting
> > dpatch-based packages to quilt is a total waste of manpower.
> 
> If your dpatches are simply patches and not scripts, converting to 3.0
> (quilt) is a few minutes job: rename the files, rename 00list to series,
> adapt its content, remove your patch system from debian/rules, change
> the build-deps accordingly, write a debian/source/format file containing
> 3.0 (quilt). Done.
I think dpatch is much easier to use and simpler to debug than quilt (yes I
use both systems). 

So I still don't see a reason to convert. 

For many packages (one upstream, already working patch system) converting to
quilt just means more work. 

source 3.0 (quilt) is still missing tools to make it working out of the box.
If you quilt not only in debian packages its fucking annoying that you need
to change to patch of your patches from patches/ to debian/patches depending
on what you are working on. 

IMHO 3.0 would have been much more successfull if it wouldn't have called
quilt and dpkg would have all tools needed to work with the system (push,
pop, create patch and so on). 

The way it is now, I don't see a reason to invest the extra work.

Just my 2 cent

Alex


-- 
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/20100220113343.ga20...@apu.snow-crash.org

Re: Misc developer news (#21)

[Alexander Wirt]

Alexander Wirt schrieb am Saturday, den 20. February 2010:

> Mike Hommey schrieb am Saturday, den 20. February 2010:
> 
> > On Sat, Feb 20, 2010 at 09:03:10AM +0100, Marc Haber wrote:
> > > On Fri, 19 Feb 2010 18:51:11 +0100, Raphael Hertzog
> > >  wrote:
> > > >On Fri, 19 Feb 2010, Marc Haber wrote:
> > > >> On Fri, Feb 19, 2010 at 12:08:16PM +0100, Raphael Hertzog wrote:
> > > >> >   * More than 1000 source packages[4] are already using the new 
> > > >> > source
> > > >> > formats "3.0 (quilt)" and "3.0 (native)". Have you updated your 
> > > >> > own
> > > >> > packages already?
> > > >> 
> > > >> Why should I?
> > > >
> > > >http://wiki.debian.org/Projects/DebSrc3.0#WhyshouldIconvertmypackageto3.0.28quilt.29format.3F
> > > 
Please forget my previous mail, after reading it again I detected some lack
of coffee in my english (in fact weasel detected it). So let me rephrase my
thoughts. 

Currently I don't see much reasons to convert most 1.0 packages to 3.0. I
don't see any advantages for packages which already have a patchsystem and
which only have one upstream source. 

I'm still looking for reasons to convert to 3.0.

Things would be much easier for starters if dpkg would ship its own patch
helpers like push, pop and create patch. A 3.0 format which is working out of
the box without installing quilt and without the need to set QUILT_PATCHES 
would be a real benefit for everybody. 

Also the dpkg maintainer shouldn't beg maintainers to switch 3.0. If the
format has advantages and works without problems people will switch
automatically. And the last thing I want to see is that NMUs (or binNMUs)
convert a package to 3.0 unless the maintainer explicitly agreed to it. 

Alex


-- 
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/20100220120755.gb20...@apu.snow-crash.org

Bug#573880: ITP: icinga -- A host/service/network monitoring and management system

[Alexander Wirt]

Package: wnpp
Severity: wishlist
Owner: Alexander Wirt 

* Package name: icinga
  Version : 1.0.1 
  Upstream Author : Icinga Team 
* URL : http://www.icinga.lorg/
* License : GPL
  Programming Lang: C
  Description : A host/service/network monitoring and management system

 Icinga is a monitoring and management system for hosts, services and
 networks. icinga-common contains the common files for the icinga package.
 .
 Icinga's features include:
 .
  *  Monitoring of network services (via TCP port, SMTP, POP3, HTTP, NNTP,
 PING, etc.)
  *  Plugin interface to allow for user-developed service checks
  *  Contact notifications when problems occur and get resolved (via email,
 pager, or user-defined method)
  *  Ability to define event handlers to be run during service or host events
 (for proactive problem resolution)
  *  Web output (current status, notifications, problem history, log file, etc.)
 .
 Icinga is designed to be easy to understand and modify to fit your own needs.
 .
 Upstream URL: http://www.icinga.org/


This does not include the new icinga php based webfrontend, if you are
interested in maintaining it feel free to join us in the nagios team. 

Since we are currently a two man show, any other help would also be
appreciated. 
 

Alex



-- 
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/20100314173808.31237.74772.report...@nelson.snow-crash.org

Re: About new source formats for packages without patches

[Alexander Wirt]

Raphael Hertzog schrieb am Friday, den 26. March 2010:

> On Fri, 26 Mar 2010, Stéphane Glondu wrote:
> > Raphael Hertzog a écrit :
> > > Note that the lintian message specifically requests to contact us if you
> > > decide to stick with 1.0 for such a technical reason. That's done that way
> > > so that I can help resolve those problems. No later than this morning I
> > > contacted the launchpad guys to allow new source formats in karmic PPA
> > > because one DD continued to use 1.0 for this reason.
> > 
> > Did they reply? AFAIC, the same applies to jaunty PPA and lenny-backports.
> 
> Yes, they are going to allow it for karmic PPA. I just asked for jaunty
> too.
> 
> lenny-backports needs a dak upgrade and formorer doesn't want to do it,
> maybe someone else should offer him to manage it for him.
Thats not true. What I said to you is that we won't upgrade dak before
backports.debian.org as this would mean doubling the work. 

Alex


-- 
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/20100326131539.gi1...@hawking.credativ.lan

Re: backports.debian.org

[Alexander Wirt]

Raphael Hertzog schrieb am Friday, den 26. March 2010:

> On Fri, 26 Mar 2010, Alexander Wirt wrote:
> > Raphael Hertzog schrieb am Friday, den 26. March 2010:
> > > lenny-backports needs a dak upgrade and formorer doesn't want to do it,
> > > maybe someone else should offer him to manage it for him.
> > Thats not true. What I said to you is that we won't upgrade dak before
> > backports.debian.org as this would mean doubling the work. 
> 
> Has it been decided that backports.debian.org would be a separate
> dak installation?
Afaik the whole thing will be on a separate box. 

> Otherwise it might well be that the backports suite are going to be
> directly managed on ftp-master.debian.org. That way it's
> automatically mirrored, etc.
Regardless of the place I don't have root on the box and can't do anything
for it. Its all up to ftpmaster. So please don't beg me anymore. thanks. 

> Also I fail to see why the upgrade would have to be done twice.
> Either you do it now and you can copy the database and the files to
> backports.debian.org or you don't and you'll have to do it on the new
> installation anyway. What do I miss?
Because you don't have a clue how things are going. 

Alex


-- 
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/20100326182152.ga27...@nelson.snow-crash.org

Re: Too much disruptive NMUs

[Alexander Wirt]

Jari Aalto schrieb am Sunday, den 23. May 2010:

Hi, 

*snip*
> In addition to fixing the RC bugs, minor updates were usually done at
> the same time. This was done for the reasons that in case the packages
> were later orphaned or the maintainer were MIA, it would be more
> desireable to have a well shaped package in archive. The minor changes
> include:
> 
> - update to latest debhelper (In many times no debian/rules changes;
>   possibly update deprecated dh_clean to dh_prep")
> - use packaging format 3.0 (delete quilt if it was used)
> - update compat to 7
I don't find anything of them acceptable for an nmu.
> The DEP1 does't specifially encourage fixing anything else than the BUG
> at hand, and that's a very good rule for actively maintained packages.
That dep thingys are no policy. imho these uploads violate the nmu policy. 

 
Alex


-- 
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/20100523132511.ge16...@lisa.snow-crash.org

Re: xulrunner 1.9.2 into sid?

[Alexander Wirt]

Michael Gilbert schrieb am Tuesday, den 29. June 2010:

Hi, 

> In my personal opinion, the only viable option left is to drop all
> mozilla and mozilla-depending packages from main, and provide them in
> backports (as suggested already in another message in this thread).
> Backports' rolling release model makes it the perfect avenue to adhere
> to mozilla's dictated treadmill.  It may take quite a bit of work to
> excise the offending packages, but there is still quite a bit of time
> before the squeeze freeze; so it should be doable.  With respect to 
> upgrades from lenny, perhaps the iceweasel packages could upgrade to
> epiphany or chromium and provide a message about using backports
> informing the user about how to continue using iceweasel if that's
> really what they want.
You should talk with the backports ftpmaster before (yes thats me). 

Alex - Not happy about the idea. 


-- 
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/20100629202247.ga4...@lisa.snow-crash.org

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

[Alexander Wirt]

Hi, 

> Dear Alexander, backport.org people, and everybody,
> 
> If I understand correctly, it is planned to incorporate the backports.org
> service as an official Debian repository.
Thats true. 
> 
> I would like to know if the policy of use for backports.debian.org has already
> been discussed, drafted or decided. In particular:
The current agreement is that everything will stay the same and that future
changes will stay in the hands of the backports team. 

>  - Will there still be separate keyrings?
Thats not clear yet, currently it seems - due to technical limitations in dak
- we will start with our own dak instance which means with our own keyring.
But this will be changed in the future. 

>  - Will there still be a screening at the first upload: a NEW queue?
Yes. 
>  - Who will be allowed to upload backports?
Every DD and probably every DM after he is added to our keyring. 

>  - Will the upload policy change?
There are some small changes planned, but nothing fundamental. 

> The current upload policy is well adapted to the fact that a backport can be
> maintained by a different person from the official package maintainers. But
> when backports are prepared by the same team as the main package, can the 
> rules
> be relaxed ?
I don't understand this question. Currently its already possible - and
preferred - if the maintainer of a package also work on the backport. I don't
see what can be relaxed here. 

> Lastly, in echo to the xulrunner thread, I would like to know if it will be
> possible to maintain a pakcage in backports.org when it is not targetted at a
> stable release (for instance, when the program is still in a fast development
> stage).
I don't think so. Rhonda (who will get a new ftpmaster for bpo if we moved)
thinks like me. For a simple package like flashplugin-nonfree this is
possible, but xulrunner is a monster with all its dependencys and its a
security nightmare. I don't see that backports is appropriate for such a
package. 

Alex


-- 
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/20100630065023.gd4...@lisa.snow-crash.org

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

[Alexander Wirt]

Charles Plessy schrieb am Wednesday, den 30. June 2010:

Hi, 

*snip*

> Thanks for the fast answer!
> 
> First of all, I would like to make clear that I am not trying to bikeshed
> xulrunner: I am more self-centered than this and was only thinking on how to
> use backports.debian.org for the Debian Med packages (this is why I opened a
> separate thread).
> 
> When I asked about relaxing the rules, I was in particular thinking about
> upload of backports prepared by the original maintainer, before testing
> migration. For instance in some cases, it is crystal clear from the debdiff 
> and
> the maintainer's tests on his computer that some changes uploaded to unstable
> will not introduce new bugs. Updating the backport at the same time would save
> some time and simplify our schedules (no upload echo 10 days later). The other
> constraint that I would be interested to be lifted is the passage through the
> NEW queue when the backport maintainer is the original maintainer, but if it
> requires toolchain development, I understand that this would not be done 
> (again
> the goal is to remove issues from the radar after upload).
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). 

I want well tested packages in bpo (which means tested by users, not
uploaders). 

> I think that backports.debian.org will be a tremendous addition to our
> distribution, that will distinguish us from many others, and I thank you for
> all the hard work and perseverence that lead to this. Since it opens many
> possibilities, I think that it is important to have a discussion in advance to
> make sure that the vision of the uploaders and the administrators fit well. In
> particular, I think that the question of whether backports should only exist
> for packages that are aimed at a stable release is a very important one. For
> some of the packages I maintain, I predict that my users will be much more
> interested in snapshots (to be consistent over a project) or backports of the
> main package. In that sense, although the package in stable may be released 
> and
> maintained with care, it will be more a byproduct than the real aim.
I have the vision of well tested packages, maintained by experienced
developers users can trust in. 

This is how I run backports.org and I plan to continue it. I don't want
backports as a place for snapshot or to deliver development packages to
users. 

> By the way, will the backports.debian.org uploads archived on
> snapshots.debian.org?
This is already done for backports.org and will be continued if the service
is offical. 


Alex


-- 
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/20100630105824.gc6...@hawking.credativ.lan

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

[Alexander Wirt]

Andrei Popescu schrieb am Wednesday, den 30. June 2010:

> On Mi, 30 iun 10, 12:58:25, Alexander Wirt wrote:
> > Charles Plessy schrieb am Wednesday, den 30. June 2010:
> > > 
> > > When I asked about relaxing the rules, I was in particular thinking about
> > > upload of backports prepared by the original maintainer, before testing
> > > migration. For instance in some cases, it is crystal clear from the 
> > > debdiff and
> > > the maintainer's tests on his computer that some changes uploaded to 
> > > unstable
> > > will not introduce new bugs. Updating the backport at the same time would 
> > > save
> > > some time and simplify our schedules (no upload echo 10 days later). The 
> > > other
> 
> > 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.
Send patches :)

Alex


--
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/20100630111859.gd6...@hawking.credativ.lan

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

[Alexander Wirt]

Charles Plessy schrieb am Wednesday, den 30. June 2010:

> Hello again,
> 
> I have another question: backports-user is quite high traffic, but to upload
> backports it is required to be subscribed. Will this change for
> backports.debian.org? Will the users be invited to use the BTS?
Not, currently the bts is not able to reflect the situation that we have
different and changing maintainers. As soon as somebody has a solution for me
we will move to it. Currently I don't have one. 

Alex


-- 
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/20100630130516.ge6...@hawking.credativ.lan

Re: another disadvantage of backports

[Alexander Wirt]

Holger Levsen schrieb am Wednesday, den 30. June 2010:

> backports.org is (currently) not available for all debian archs.
same as experimental. 





signature.asc
Description: Digital signature

Re: Bug#594897: ITP: icinga -- A host/service/network monitoring framework forked from Nagios

[Alexander Wirt]

Daniel Keyhani schrieb am Monday, den 30. August 2010:

Hi, 
 
> * Package name: icinga
>   Version : 1.0.2
>   Upstream Author : Icinga Development Team 
> * URL : http://www.icinga.org/
> * License : GPL
>   Programming Lang: C
>   Description : A host/service/network monitoring framework forked from 
> Nagios
> 
> Icinga is an enterprise grade open source monitoring system which keeps watch 
> over a network and any 
> conceivable network resource, notifies the user of errors and recoveries, and 
> generates performance 
> data for reporting. Scalable and extensible, Icinga can monitor complex, 
> large environments across 
> dispersed locations. In a nutshell, Icinga allows you to:
You mean that one:
icinga |1.0.2-1 |   testing | source, amd64, armel, hppa, i386,
   ia64, mips, mipsel, powerpc, s390, sparc
icinga |1.0.2-1 |  unstable | source, alpha, amd64, armel,
   hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
icinga |1.0.3-1 |  experimental | source, alpha, amd64,
   armel, i386, ia64, mipsel, s390, sparc

Alex


-- 
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/20100830143455.gb25...@hawking.credativ.lan

Re: backports.org moved to backports.debian.org

[Alexander Wirt]

gregor herrmann schrieb am Monday, den 06. September 2010:
 
Hi, 

> > You should also update your dput/dupload config, uploading to
> > backports-master.debian.org instead of www.backports.org
> 
> http://backports.debian.org/Contribute/ talks about
> backports.debian.org, something is confusing here :)
You are right, I fixed the docs. 

Alex
-- 
Alexander Wirt, formo...@formorer.de 
CC99 2DDD D39E 75B0 B0AA  B25C D35B BC99 BC7D 020A


-- 
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/20100906073325.ga10...@hawking.credativ.lan

Re: Backports service becoming official

[Alexander Wirt]

Lucas Nussbaum schrieb am Tuesday, den 07. September 2010:

Hi, 

> > > Alexander Reichle-Schmehl writes ("Backports service becoming official"):
> > > > Because of limitations in the Debian Bug Tracking System, any bugs
> > > > relevant to backported packages still have to be reported to the
> > > > debian-backports [3] list, which have now also been moved to
> > > > lists.debian.org [4].
> > > 
> > > What are the BTS limitations ?  Perhaps it could be improved to
> > > support backports too.  Using mailing lists for this is a bit 1980's :-)
> > 
> > From what I understand it's the version tracking and the fact that 
> > backports can have a different Maintainer then the "regular" package.
> 
> Now that backports are becoming official, I think that it is the right
> time to reconsider the maintenance model of backports. I would
> personally prefer if we had the same rules of packages ownership as for
> normal packages ("normal" backport maintainer = maintainer of the
> package in unstable).
I completly disagree here. backports are different and I don't think I'll
ever treat them as you like. Thats exactly the type of bureaucracy I feared
when I got asked if I want to have backports official.

Don't expect that to happen until I am responsible for backports.

Alex


-- 
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/20100907170724.ga12...@nelson.snow-crash.org

Re: Bugs in Backported Packages

[Alexander Wirt]

Rene Engelhard schrieb am Thursday, den 09. September 2010:

> On Wed, Sep 08, 2010 at 01:22:24PM -0700, Don Armstrong wrote:
> > 1: It's certainly a bug in the backported package using debhelper
> > improperly; it may also be an additional wishlist bug in debhelper.
> 
> I disagree, the backported package uses debhelper correctly. Especially
> if you don't use the backported debhelper, too, you just have to rely
> on that debhelper would do it correctly.
> 
> Or do you really want debian/rules checking which debhelper you use
> and add postinst/postrm snippets then after it noticed that dh_desktop
> in theory should add something (because this is lenny) but doesn't?
> 
> The debhelper backport simply should have made debhelper working in lenny
> by reverting the change.
> 
> For that matter, I have this in debian/rules already:
> 
> ifeq "$(LENNY_BACKPORT)" "y"
> dh_desktop -s
> endif
> 
> Because dh_desktop is not needed anymore on sarge/sid but on lenny.
> But lenny-backports' debhelper doesn't do anything here like the
> version in sarge/sid (whereas lennys version does, and that's what is
> the expected environment inside lenny)
I'll fix that. 

Alex
 


-- 
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/20100909084321.gb4...@hawking.credativ.lan

Re: ITP: shinken -- Monitoring tool

[Alexander Wirt]

david hannequin schrieb am Monday, den 04. October 2010:

Hi, 

> Version: N/A; reported 2010-09-16
> Severity: wishlist
> 
> Package name: shinken
> Version: 0.2.1
> Upstream Jean Gabes jean.ga...@gmail.com
> URL: http://www.shinken-monitoring.org
> License: GPL
> Description:
> Source: http://shinken-monitoring.org/pub/shinken-0.2.1.tar.gz
Even if I think shinken is not ready for productive usage its good to see
that someone packages it. I want to invite you to do the packaging and 
maintenance
within the existing pkg-nagios group as shinken is more or less nagios related
:). If you are interested join us on the mailinglist
(pkg-nagios-de...@lists.alioth.debian.org) and in the pkg-nagios alioth
project. 

Thanks for your attention

Alex 


-- 
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/20101004124607.ge15...@hawking.credativ.lan

Re: RFA: all my packages

[Alexander Wirt]

Decklin Foster schrieb am Thursday, den 10. February 2011:

> I'm looking for a new maintainer for, well, any of these. My heart is
> not in it anymore and most of them have been neglected for a while.
> Recently my free time has been taken up by other things (mainly my job)
> and I forsee that continuing.
> 
> http://qa.debian.org/developer.php?login=decklin%40red-bean.com
As I am a heavy mpd user I would like to take these over and form a team for
mpd related packages. Are they still for adoption?

Alex



signature.asc
Description: Digital signature

Re: RFA: all my packages

[Alexander Wirt]

Reinhard Tartler schrieb am Friday, den 11. February 2011:

> On Fr, Feb 11, 2011 at 07:12:05 (CET), Alexander Wirt wrote:
> 
> > Decklin Foster schrieb am Thursday, den 10. February 2011:
> >
> >> I'm looking for a new maintainer for, well, any of these. My heart is
> >> not in it anymore and most of them have been neglected for a while.
> >> Recently my free time has been taken up by other things (mainly my job)
> >> and I forsee that continuing.
> >> 
> >> http://qa.debian.org/developer.php?login=decklin%40red-bean.com
> > As I am a heavy mpd user I would like to take these over and form a team for
> > mpd related packages. Are they still for adoption?
> 
> If our team rules/development guidelines (basically the git-buildpackage
> recommended workflow)suit your development style, you could join and
> maintain the mpd packages in the pkg-multimedia team:
> 
> http://wiki.debian.org/DebianMultimedia/
I'm not sure (I am a little bit old-fashioned) but I'll have a look.

Thanks for the hint
Alex


-- 
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/20110211142146.ge3...@smithers.snow-crash.org

Re: RFA: sonata, mpdscribble,...

[Alexander Wirt]

Michal Čihař schrieb am Friday, den 11. February 2011:

> Hi
> 
> as I don't use MPD for quite a long time now, it somehow does not make
> sense to maintain MPD related packages anymore. Simply I don't
> have environment to test them.
> 
> The packages given for adoption are:
> 
> mpdris
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612907
> 
> mpdscribble
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908
> 
> python-mpd
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612909
> 
> sonata
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612910
In general it would be good if all those package would be maintained under
the "to be formed" new mpd team. I'll request a new alioth project for mpd
later. It would be nice to have all mpd related packages in that team. 

Alex



signature.asc
Description: Digital signature

Re: RFA: all my packages

[Alexander Wirt]

Alexander Wirt schrieb am Friday, den 11. February 2011:

> Decklin Foster schrieb am Thursday, den 10. February 2011:
> 
> > I'm looking for a new maintainer for, well, any of these. My heart is
> > not in it anymore and most of them have been neglected for a while.
> > Recently my free time has been taken up by other things (mainly my job)
> > and I forsee that continuing.
> > 
> > http://qa.debian.org/developer.php?login=decklin%40red-bean.com
> As I am a heavy mpd user I would like to take these over and form a team for
> mpd related packages. Are they still for adoption?
Just for the record - I created pkg-mpd on alioth. Feel free to join if you
are interested in maintaing mpd related packages. 

Alex


-- 
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/20110211183326.gh3...@smithers.snow-crash.org

Re: RFA: sonata, mpdscribble,...

[Alexander Wirt]

Alexander Wirt schrieb am Friday, den 11. February 2011:

> Michal Čihař schrieb am Friday, den 11. February 2011:
> 
> > Hi
> > 
> > as I don't use MPD for quite a long time now, it somehow does not make
> > sense to maintain MPD related packages anymore. Simply I don't
> > have environment to test them.
> > 
> > The packages given for adoption are:
> > 
> > mpdris
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612907
> > 
> > mpdscribble
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612908
> > 
> > python-mpd
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612909
> > 
> > sonata
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612910
> In general it would be good if all those package would be maintained under
> the "to be formed" new mpd team. I'll request a new alioth project for mpd
> later. It would be nice to have all mpd related packages in that team. 
I created https://alioth.debian.org/projects/pkg-mpd/ and if you are
interested in an mpd team please join pkg-mpd-maintain...@alioth.debian.org.

Alex


signature.asc
Description: Digital signature

Re: enable/disable support in /usr/sbin/service

[Alexander Wirt]

Stefano Zacchiroli schrieb am Freitag, den 04. März 2011:

> On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote:
> > At present there *is* no reliable sysadmin interface for enabling/disabling
> > services.  update-rc.d is not it; many admins have been using 'update-rc.d
> > -f remove' for years, but this is /wrong/ and it is /documented/ that this
> > will cause the links to be readded on package upgrade.  policy-rc.d is not
> > it; the spec for this is bloated and I've never heard of an admin who's ever
> > bothered implementing anything more than a "don't start any services in a
> > chroot" policy using this.  And /etc/default/* isn't it; no consistent
> > variable naming, not implemented for all services (and shouldn't be), so
> > it's not scriptable, so it requires vi.
> > 
> > So the mv command above *is* the current method.  And we're in desperate
> > need of a better one.
> 
> Right, this is the technical problem to solve: find one (handy) method
> to enable/disable services and "bless" it as the recommended one.
> 
> There seems to be a bug report against sysvinit-utils (that package
> which ships /usr/sbin/service) about this already: #545325. I'm cc-ing
> the bug log with this mail. For the bug log reference, this discussion
> started on -devel at
> .
> 
> Assuming a kind soul devises a patch for #545325, which shouldn't be
> *that* hard, would that be enough to fix the general problem or would we
> need something else in addition? (beside documentation, of course)
> 
> In particular, considering the possibility of other init systems coming
> (see #591791), would /usr/sbin/service enable/disable still be a proper,
> init-system-independent, abstraction?
I don't see a problem in shipping my own server implementation with file-rc
is neccessary. 

Alex



signature.asc
Description: Digital signature

Re: enable/disable support in /usr/sbin/service

[Alexander Wirt]

Steve Langasek schrieb am Friday, den 04. March 2011:

> On Fri, Mar 04, 2011 at 01:21:02PM +0100, Alexander Wirt wrote:
> > > In particular, considering the possibility of other init systems coming
> > > (see #591791), would /usr/sbin/service enable/disable still be a proper,
> > > init-system-independent, abstraction?
> > I don't see a problem in shipping my own server implementation with file-rc
> > is neccessary. 
> 
> As Tollef points out, there needs to be a way to make sure that running
> 'service disable' while one system is running doesn't cause the service to
> be reenabled when changing init / rc systems.  So this needs to be centrally
> maintained, somehow.
Ah good point, I missed that. 

Thanks
Alex



signature.asc
Description: Digital signature

Re: Bug#617999: Please include link to general info in each lists page

[Alexander Wirt]

Michelle Konzack schrieb am Thursday, den 17. March 2011:

> Hello Andrei Popescu and Listmasters,
> 
> it would be nice, if  could implement an autoresponder
> for peoles sending messages to lists without being subscribed.
Eh no. Autoresponder are a plague. 

Alex


-- 
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/20110318061041.ga28...@lisa.snow-crash.org

Re: cdn.debian.net as a project service?

[Alexander Wirt]

Michael Vogt schrieb am Monday, den 21. March 2011:

> On Sun, Mar 20, 2011 at 01:35:23AM -0600, Raphael Geissert wrote:
> [..]
> > P.S. apt also provides a "mirror" method (just like http, ftp, etc) but I 
> > consider it to be suboptimal and a poor way to tackle the problem.
> 
> Why exactly do you feel this way? What problems do you see with it? 
> 
> I see some benefits in the mirror method like that the mirror list is
> cached locally (on apt-get update) so the mirror service is hit less
> often. Also if the central service is down apt can still use the
> cached local info. Plus it supports automatic retry if a mirror fails.
I agree here. Some kind of local override would also be nice. It would be
nice if I can run my own local mirror service, for example on my laptop I
want to use some local mirrors if I am in a specific network. Afaik there is
currently no way to dynamically choose a mirror in apt, based on a local
decision. 

Alex


-- 
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/20110321154856.gc11...@smithers.snow-crash.org

Bug#216772: ITP: fisg -- Fast IRC Statistics Generator

[Alexander Wirt]

Package: wnpp
Severity: wishlist

* Package name: fisg
  Version : 0.3.8
  Upstream Author : Matti Hamalainen (ccr) <[EMAIL PROTECTED]>
* URL : http://www.tnsp.org/fisg.php
* License : (GPL)
  Description : Fast IRC Statistics Generator

Generates a webpage with statistics about an IRC channel.
It read logs from irssi,mIRC or eggdrops and turns them into 
a nice looking statistics web page.

See http://www.tnsp.org/fisg.php for more Informations and 
http://www.midguard.de/stats.html for a demo. 


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bart 2.4.21 #2 Thu Jul 24 10:50:08 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Bug#220890: ITP: eyed3 -- Display and manipulate id3-tags on the command-line

[Alexander Wirt]

Package: wnpp
Severity: wishlist

* Package name: eyed3
  Version : 0.5.1
  Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
* URL : http://www.travisshirk.net/eyeD3/
* License : GPL
  Description : Display and manipulate id3-tags on the command-line

A command-line editor to add/edit/remove id3-tags on mp3 files.
It supports id3 tags version 1.0,1.1,2.3 and 2.4. 
Additionally it display several informations about the file 
(length, bitrate, sample rate ...). 

-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bart 2.4.21 #2 Thu Jul 24 10:50:08 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

Bug#220888: ITP: python-eyed3 -- Python module for id3-tags manipulation

[Alexander Wirt]

Package: wnpp
Severity: wishlist

* Package name: python-eyed3
  Version : 0.5.1
  Upstream Author : Travis Shirk <[EMAIL PROTECTED]>
* URL : http://www.travisshirk.net/eyeD3/
* License : GPL
  Description : Python module for id3-tags manipulation

python-eyed3 is a python module for id3-tags manipulation. 
It supports Version 1.0,1.1,2.3 and 2.4 id3-tags. It also 
allows to retrieve informations like length, bitrate from 
the mp3 file.


-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux bart 2.4.21 #2 Thu Jul 24 10:50:08 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (ignored: LC_ALL set to [EMAIL 
PROTECTED])

RE: Bug#223781: [RFA]: usemod-wiki -- Perl-based Wiki clone

[Alexander Wirt]

Am Fr, den 12.12.2003 schrieb Julian Mehnle um 15:32:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Benjamin Drieu wrote:
> > I no longer use usemod-wiki and thus have no time to maintain it.
> > Package is in good shape, no serious bugs.  Very few work is needed to
> > maintain it as release cycle is quite long.
> > 
> > The only one todo item is to package version 1.0, which requires some
> > changes to the wiki database.  Peter Gervai <[EMAIL PROTECTED]> has
> > already made a package for this and is going to NMU usemod-wiki.  But
> > as he does not have time to adopt it, we need a new maintainer.
> 
> As I'm using UseMod Wiki on a slew of Debian machines, I'd be more than
> willing to continue maintaining usemod-wiki, but I'm no Debian Developer,
> so I'd need a sponsor until I decide and manage to become one.
I use it on some systems too, so I would be pleased to be your sponsor.
Get in touch with me if you have packages ready for upload/inspection.

formorer

-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de 
Encrypted and Signed Email preferred.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

aag - wrapper for apt-get with support for recommend and suggests field

[Alexander Wirt]

Hi folks, 

i have written a small wrapper for apt-get that makes it possible to
install all recommended and/or suggested Packages for a Package too. 
A simple Call of: aag -rs  would install all recommended and
suggested Packages for . The Code isn't very nice, but it works
fine for me. I other people are interested in using this wrapper I would
clean the code up and insert some features. Just take a look at:
http://www.formorer.de/code/aag/aag
Its just a small Perlscript with getopts and pod2usage as dependencys. 

I would be pleased to hear some comments from you. 

sincerly formorer

-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Alexander Wirt]

Am Die, 2003-04-29 um 13.08 schrieb David Nusinow:
> On Tue, Apr 29, 2003 at 06:13:38AM +0200, Alexander Wirt wrote:
> > Hi folks, 
> > 
> > i have written a small wrapper for apt-get that makes it possible to
> > install all recommended and/or suggested Packages for a Package too. 
> > A simple Call of: aag -rs  would install all recommended and
> > suggested Packages for . The Code isn't very nice, but it works
> > fine for me. I other people are interested in using this wrapper I would
> > clean the code up and insert some features. Just take a look at:
> > http://www.formorer.de/code/aag/aag
> > Its just a small Perlscript with getopts and pod2usage as dependencys. 
> > 
> > I would be pleased to hear some comments from you. 
> 
> Why not just use aptitude?[1]
Its interactive, I don't want to launch a GUI if I want so simple add a
package. Additionally it seams that aptitude is currently broken in Sid.
So this are two good reasons for me.

formorer
-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.

Re: aag - wrapper for apt-get with support for recommend and suggests field

[Alexander Wirt]

Am Die, 2003-04-29 um 17.01 schrieb Rene Engelhard:
> Hi,
> 
> Alexander Wirt wrote:
> > Its interactive, I don't want to launch a GUI if I want so simple add a
> 
> eh?
> 
> aptitude install
> aptitude remove
> aptitude purge
I'm really sorry, but this sound very new to me. But its very nice to know. 
I have to give aptitide another chance if its back in the pool.

> from command line.
> 
> > package. Additionally it seams that aptitude is currently broken in Sid.
> > So this are two good reasons for me.
> 
> apt 0.5.5 shows Suggested and Recommended packages during
> installation..
> apitude can be fixed when the new apt will be in sid...
*wait*

Best regarss 

formorer
-- 
Alexander "formorer" Wirt   KeyID: BC7D020A
EMail: [EMAIL PROTECTED] ICQ: 28651245
WWW: http://www.formorer.de
Encrypted and Signed Email preferred.

Re: lenny-backports started

[Alexander Wirt]

Luk Claes schrieb am Friday, den 20. February 2009:

> Alexander Wirt wrote:
> 
> > Thanks to the unoffical buildd network we are also able to provide autobuild
> > packages for the following architectures: arm, armel, amd64, ppc, i386, ia64
> > und alpha. Possibly mips and sparc will follow. You can find more 
> > informations about the buildstatus of a package at the buildd webinterface 
> > at http://buildd.ayous.org/. 
> 
> Any reason why you don't mention s390, it was the first arch to be ready
> for lenny-bpo AFAIK?
He told me he wasn't sure about the state of s390 so I decided to let it out. 
But good to know its ready. 

Alex


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

Re: Debian @Linuxtag 2009 - Last call for help

[Alexander Wirt]

Leo 'costela' Antunes schrieb am Monday, den 25. May 2009:

Hi Leo, 

> Alexander Wirt wrote:
> > I think that two people are not enough to run a booth. If this call for
> > help does not succeed I'll have to cancel the booth. So if you are in Berlin
> > during June 24th - 27th please be so kind and participate to the Debian
> > booth. You don't have to be a Linux/Debian expert, just a little bit
> > motivated :).
> 
> Would a foreigner whose German's not exactly top notch help?
> I live in NRW, but could gladly spend a few days in Berlin if you think
> it would be of any assistance.
Sure. Your help is really welcome. Please add yourself to the wiki and have a
few nice days in Berlin ;). 

thanks for your help

Alex
 


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

Re: Alioth tracker

[Alexander Wirt]

On Wed, 25 Jun 2014, Raphael Hertzog wrote:

> FTR I used to be an Alioth admin, so I have some experience with the
> work involved.
> 
> On Wed, 25 Jun 2014, Russell Stuart wrote:
> > Sorry to be blunt Raphael, but your response looks like a series of
> > platitudes designed to settle down the politics.  Alioth's maintenance
> > is in serious trouble.  It is unusable to many projects on it, and it is
> > clear from it's own bug reporting systems this has been the case for
> > years.
> 
> You're painting a picture which is worse than the reality. I agree
> that nobody is looking at the tickets regularly and that mails to
> ad...@alioth.debian.org tends to not get an answer but there are admins
> and they are not entirely unavailable. Up to now I always managed to get
> answer to my requests even though if often requires pinging the admins
> via #alioth.
> 
> > Deciding to accept an offer of help requires a lot of work.  You have to
> > find a graduated set of tasks that allows you to gain confidence in the
> > persons abilities, and closely monitor how well they perform them.  It
> > looks to me like the effort required is beyond the Alioth team.
> 
> That's true, it's difficult to get enough confidence in someone that
> has not some history of contribution and to give them root rights.
> 
> On Wed, 25 Jun 2014, Matthias Urlichs wrote:
> > In this case, gradually transitioning people to admins probably won't work:
> > somebody needs to monitor the new guys+gals and give them a couple of
> > rights to start with … and then, after some time, a couple of more rights …
> > and who says that my "I want to help" request will be looked at, much less
> > my "I'm ready for more opportunities to cause untold damage, give them to
> > me" mail, next month?
> > 
> > Instead, get a couple of volunteers and give them full admin rights from
> > the start. Some will blunder their way through and some will quit after a
> > week, but when the shakedown is done there's at least a chance that some of
> > them will stay with it (and not break things too badly).
> 
> This happened a few times already but only with well know DD. Cyril
> Brulebois  got root rights over night after having
> provided a few patches to multiple configuration files. I believe he
> dropped off quickly because he does many other things already but still...
> Alexander Wirt  also joined the team not so long ago
> AFAIK.
More or less. If I am around and if things are possible without too much
insight into fusionforge I am trying to help as much as I can. 

I really need some time to get more knowledge about fusionforge.

Alex


-- 
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/20140625065431.gj21...@formorer.de

Re: Making -devel discussions more viable

[Alexander Wirt]

On Mon, 07 May 2012, Raphael Hertzog wrote:

> On Sun, 06 May 2012, Chris Knadle wrote:
> > On Thursday, May 03, 2012 02:50:41, Raphael Hertzog wrote:
> > > Maybe we need a private DD-only list where people interested in
> > > improving our lists can CC their private complaints. listmasters
> > > could follow the list and take action when they notice that
> > > the same person got multiple complaints.
> > 
> > FWIW there's a [debian-private] mailing list:
> >debian-private: Private discussions among developers 
> > 
> > and this list is not archived.
> 
> Heh, thank you for the notice. But I knew about this list (and any DD knows
> about it since most of us are subscribed and it's one of the first things
> that you do when you get the DD status) and it's really not its purpose.
> 
> I believe that such mails should not be imposed to debian-private readers
> but only to people who specifically opted to help "moderate" our mailing
> lists through "social influence".
I am just speaking for myself as listmaster. But I don't think any DD has
more "right" to talk on a mailinglist than anybody else. I won't support such
a proposal nor want I participate in it. If you have a problem with someone
on a mailinglist, report it and listmasters decide if we should step in.

Alex - with his - personal - listmaster hat on


-- 
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/20120507071354.ga26...@smithers.snow-crash.org

Re: on the use of chmod/chown in maintainer scripts

[Alexander Wirt]

On Sun, 13 May 2012, Leo "costela" Antunes wrote:

> Hi,
> 
> On 12/05/12 12:23, Peter Palfrader wrote:
> > This may not be entirely trivial to solve.  find | xargs constructs at best
> > mitigate this to a race.  While chown does have a --no-derefence flag, this
> > does not protect us in the case of hardlinks.  chmod has no such flag, and 
> > it'd
> > useful only for symlinks anyway.  Neither tool has a 
> > --only-if-link-count-is-one
> > flag.
> 
> >From find(1):
> -links n
>   File has n links.
> 
> So I guess this specific problem could theoretically be solved this way.
> However, I'm actually also for a more general solution, as being
> discussed for dpkg or at least debhelper.
This creates just a race condition.

Alex
 


-- 
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/20120513154944.gc19...@smithers.snow-crash.org

Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1

[Alexander Wirt]

On Wed, 27 Jun 2012, Paul Wise wrote:

> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
> 
> > Yes.  See http://bugs.debian.org/539591 >,
> > http://bugs.debian.org/573004 > and the source of insserv, where
> > a patch to do this was created and included by Kel.  The patch has
> > been available for more than two years.
> 
> Hmm, no upload in those two years either. Is file-rc still maintained at all?
It is. But more or less in "no-new-features" mode.

Implementing the insserv stuff is wishlist for me. Even when I now get forced
into it.

Alex


-- 
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/20120627134633.gc6...@snow-crash.org

Re: [Pkg-sysvinit-devel] Future of update-rc.d in wheezy+1

[Alexander Wirt]

On Wed, 27 Jun 2012, Roger Leigh wrote:

> On Wed, Jun 27, 2012 at 04:39:38PM +0200, Bernd Zeimetz wrote:
> > On 06/27/2012 03:46 PM, Alexander Wirt wrote:
> > > On Wed, 27 Jun 2012, Paul Wise wrote:
> > > 
> > >> On Wed, Jun 27, 2012 at 6:27 PM, Petter Reinholdtsen wrote:
> > >>
> > >>> Yes.  See http://bugs.debian.org/539591 >,
> > >>> http://bugs.debian.org/573004 > and the source of insserv, where
> > >>> a patch to do this was created and included by Kel.  The patch has
> > >>> been available for more than two years.
> > >>
> > >> Hmm, no upload in those two years either. Is file-rc still maintained at 
> > >> all?
> > > It is. But more or less in "no-new-features" mode.
> > > 
> > > Implementing the insserv stuff is wishlist for me. Even when I now get
> > > forced into it.
> 
> I don't think there's any question of "forcing", but encouraging
> file-rc to retain compatibility with the init scripts being used by the
> distribution.  It looks like the patches are there, they just need
> testing.  If file-rc could have this in place for wheezy, that would
> be highly desirable, so that we can work on deprecating runlevel
> sequence numbers in wheezy+1.
Nope, there is an experimental patch for insserv to print out sequence
numbers, to get this working I first have to build my own insserv. And the
whole file-rc part is - beside of some ideas in my mind - missing.

So its unlikely to get this working unless insserv (for the patch) and
file-rc get a freeze exception.

Alex


-- 
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/20120628060233.gf6...@snow-crash.org

Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)

[Alexander Wirt]

On Sat, 11 Aug 2012, Faidon Liambotis wrote:

> On 08/11/12 01:12, Russ Allbery wrote:
> > There are choices that we don't support because the process of supporting
> > that choice would involve far more work than benefit, and the final goal
> > is excellence, not choice for its own sake.  For example, we don't allow
> > users to replace the system C library with a different one.  That's
> > something that we *could* do, but the general consensus of the project is
> > that investing our effort in that is not the best way to produce
> > excellence.
> 
> I kind of disagree with that. I don't think that the fact that we don't
> support multiple C libraries is the result of a "consensus decision".
> 
> I think it's just because noone attempted to properly do that and prove
> it's viability and usefulness either to a portion of the userbase or the
> project as a whole.
> 
> Similarly, I don't think the kFreeBSD ports or any of the other Linux
> architecture ports were a consensus decision. People just did it, the
> work was of reasonable standards and useful both to expanding the
> userbase and to improving the quality of the other ports.
> 
> People are working on building Debian with LLVM (which is great IMHO).
> Very few people complained about that and the talk was very much
> welcomed at DebConf. We even have a GSoC project about it. There are
> other similar examples.
> 
> As for OpenRC, as far as I understand it, it's similar -but with its LSB
> header compatibility much less intrusive- with file-rc. None of the two
> are an /sbin/init replacement.
In fact file-rc now supports depedency based booting and lsb headers. This is
not yet in wheezy but will hopefully get into wheezy.

Alex
 


-- 
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/20120811090705.gb8...@snow-crash.org

Re: Bug#685042: ITP: libpam-ssh -- Authenticate using SSH keys

[Alexander Wirt]

On Thu, 16 Aug 2012, Antti-Juhani Kaijanaho wrote:

> On Thu, Aug 16, 2012 at 04:14:07PM +0200, Jerome BENOIT wrote:
> > The situation is ambiguous as I posted before in the 
> > debian-devel@lists.debian.org list:
> > the package is not orphaned, was removed but it is still present.
> 
> There is no ambiguity.  The package is present in unstable and thus is not
> "removed" in the sense that word is commonly used without qualifiers.  (The
> proper way to describe what happened to the package is "removed from testing" 
> -
> a release engineering action that doesn't imply any change in a package's
> maintainership.)
What let you think this?
rmadison libpam-ssh
 libpam-ssh | 1.92-14 | squeeze | source, amd64, armel, i386, ia64,
 kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
 W: Archive maintenance is in progress; database inconsistencies are
 possible.


[Date: Fri, 02 Dec 2011 16:51:17 +] [ftpmaster: Alexander
Reichle-Schmehl]
Removed the following packages from unstable:

libpam-ssh |1.92-14 | source
libpam-ssh | 1.92-14+b1 | amd64, armel, i386, ia64, kfreebsd-amd64,
kfreebsd-i386, mips, mipsel, powerpc, s390, sparc
Closed bugs: 650644


Alex
 


-- 
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/20120816154108.gc5...@snow-crash.org

Re: Bug#688066: ITP: rex -- What do you want to deploy today?

[Alexander Wirt]

On Wed, 19 Sep 2012, Bastien ROUCARIES wrote:

> On Wed, Sep 19, 2012 at 9:52 AM, Jon Dowland  wrote:
> > On Tue, Sep 18, 2012 at 10:52:29PM +0200, Mike Gabriel wrote:
> >>   Description : What do you want to deploy today?
> >
> > A better short description is needed here. In a nutshell, what
> > does it do?
> 
> Moreover they exist a rex language interpreter
> http://en.wikipedia.org/wiki/Rex_%28programming_language%29
The rex in this ITP is no rex interpreter. It is a deployment/system
automation tool like fabric.

Alex


-- 
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/20120919170530.ga5...@snow-crash.org

Re: Candidates for removal from testing (2013-06-04)

[Alexander Wirt]

On Tue, 04 Jun 2013, "Rodolfo García Peñas (kix)" wrote:

> On 04/06/2013 14:06, Niels Thykier wrote:
> > Hi,
> > 
> > Our automated tools for finding RC buggy leaf packages in testing have
> > found 79 potential candidates (see attached files).
> > 
> > The packages have been selected based on the following criteria:
> >  * The package had at least one RC bug without activity for the past
> >14 days.
> 
> Hi,
> 
> about vlock (I use it), IMO the critical bug should have less severity
> (not grave, perhaps important).
> 
> If the package maintainers are busy, I could help them.
There are not much of us left (in fact I am the last one), so any help would
be appreciated (*hint* a co-maintainer would be nice).

Alex


-- 
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/20130605161543.ga20...@smithers.snow-crash.org

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Alexander Wirt]

gustavo panizzo  schrieb am Monday, den 26. August 2013:

> On 08/26/2013 07:33 AM, Neil McGovern wrote:
> > I'm hoping that these raising of hands are also offers to help do the
> > work to make it happen.
> i offer help, we are interested on longer maintenance for some packages.
> i think we should start to coordinate, if is anybody else willing to
> help with the work
> 
> maybe  l...@lists.debian.org? if is not possible i can host a mailing list
If there is really interest, a list on l.d.o wouldn't be a problem. Just
follow http://www.debian.org/MailingLists/HOWTO_start_list.en.html and get a
few seconders for the new list.

Alex - with his Listmaster hat on


-- 
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/20130826132854.gc21...@hawking.credativ.lan

Re: Longer maintainance for (former) stable releases of Debian (Re: Dreamhost dumps Debian)

[Alexander Wirt]

Lucas Nussbaum schrieb am Monday, den 26. August 2013:

> On 26/08/13 at 10:00 -0300, gustavo panizzo  wrote:
> > On 08/26/2013 07:33 AM, Neil McGovern wrote:
> > > I'm hoping that these raising of hands are also offers to help do the
> > > work to make it happen.
> > i offer help, we are interested on longer maintenance for some packages.
> > i think we should start to coordinate, if is anybody else willing to
> > help with the work
> > 
> > maybe  l...@lists.debian.org? if is not possible i can host a mailing list
> 
> Hi,
> 
> Long-term support of stable releases was one of the reasons for the
> debian-companies@ initiative. I'm Ccing Michael Meskes, who is
> interested in coordinating this initiative.
JFTR Coordination of LTS support should not go through a closed list.

Alex
 


-- 
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/20130826141100.gd21...@hawking.credativ.lan

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Alexander Wirt]

Wouter Verhelst schrieb am Monday, den 28. October 2013:

> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right.  Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;
> 
> While I'm not sure from your mail whether you meant to suggest otherwise, I do
> think that whatever we decide for jessie, we should continue the requirement 
> of
> sysvinit compatibility for at least one release after we ship with some more
> modern init system.
> 
> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.
It will also make backporting much easier.

Alex
 


-- 
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/20131028174046.gc9...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Gergely Nagy schrieb am Sonntag, den 27. November 2011:

Hi,

> > Recently [1], dpatch's maintainer uploaded a new version indicating
> > that dpatch is now deprecated.  Following that, he filed a bug [2] so
> > that lintian might warn that dpatch's makefile has been deprecated
> > since 2003, and that dpatch itself is now deprecated.  However, he
> > also stated that he plans to keep dpatch for wheezy.
> 
> Just for the record, to reiterate what I have said previously[1], dpatch
> will be kept around until it can be removed safely: when all reverse
> build-depends have been migrated to something else.
> 
>  [1]: http://lists.debian.org/debian-devel/2011/08/msg00380.html
> 
> That certainly won't happen before wheezy, and is unlikely to happen for
> wheezy+1, too. My plan still is to phase out dpatch by wheezy+2, but
> until then, it's a legacy that should be migrated away from, and must
> not be used for new packages.
Since there is no proper alternative (no quilt is not) I will continue to use
dpatch for all of my packages. If neccessary I would volunteer to take over
upstream.

So if you are just going for leftover rdeps it will probably never be
removed.

Alex


-- 
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/2028103201.ga3...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Gergely Nagy schrieb am Montag, den 28. November 2011:

> Alexander Wirt  writes:
> 
> >> > Recently [1], dpatch's maintainer uploaded a new version indicating
> >> > that dpatch is now deprecated.  Following that, he filed a bug [2] so
> >> > that lintian might warn that dpatch's makefile has been deprecated
> >> > since 2003, and that dpatch itself is now deprecated.  However, he
> >> > also stated that he plans to keep dpatch for wheezy.
> >> 
> >> Just for the record, to reiterate what I have said previously[1], dpatch
> >> will be kept around until it can be removed safely: when all reverse
> >> build-depends have been migrated to something else.
> >> 
> >>  [1]: http://lists.debian.org/debian-devel/2011/08/msg00380.html
> >> 
> >> That certainly won't happen before wheezy, and is unlikely to happen for
> >> wheezy+1, too. My plan still is to phase out dpatch by wheezy+2, but
> >> until then, it's a legacy that should be migrated away from, and must
> >> not be used for new packages.
> > Since there is no proper alternative (no quilt is not) I will continue to 
> > use
> > dpatch for all of my packages. If neccessary I would volunteer to take over
> > upstream.
> 
> I'd rather figure out what makes dpatch better than quilt for your
> use-cases, and go from there.
Usability. Hacks like .pc, or the hacks/patches it has for finding this
directory. 

Dpatch is small and simple, quilt is a beast that trickled me several times
in other projects. 

> Nope, I'm not going only for leftover rdeps. I'll investigate the harder
> cases too, where migration is either non-trivial, or it involves finding
> a suitable alternative (be that quilt, something built around quilt, or
> something completely different).
> 
> I planned to do this by first getting rid of the easy ones, but if
> people who prefer dpatch over other solutions step up and tell me up
> front why they're happy with dpatch, and unhappy with the things I
> consider alternatives, so much the better!
Its simple and things like dpatch-edit-patch are just great. I now use dpatch
for round 8 years and it worked every time. I don't see any reason to move
away.

And I still like the "never touch a running system" approach. If dpatch works
without problems, why deprecate it?

Alex


-- 
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/2028115457.gb3...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Raphael Hertzog schrieb am Montag, den 28. November 2011:

> On Mon, 28 Nov 2011, Alexander Wirt wrote:
> > Since there is no proper alternative (no quilt is not) I will continue to 
> > use
> > dpatch for all of my packages. 
> 
> Is it only the fact that dpatch "patches" can be scripts that justify this
> assertion?
> 
> If not, I would be interested to learn why quilt is not a proper
> alternative.
It has nothing to do with script. It is implementation and usability. 

And the problem that debians dpatchs is full of evil patches that makes it
just incompatible to other quilts on non-debian systems. 
 
Imho the whole 3.0 quilt thingy just went wrong, instead of hacking around an
existing system it would have been better to have a specialised set of tools
around dpkg. But I think I said this some time ago. 

Alex


-- 
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/2028120044.gc3...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Jon Dowland schrieb am Montag, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > And I still like the "never touch a running system" approach. If dpatch 
> > works
> > without problems, why deprecate it?
> 
> One reason is that the surface area of Debian development tools is too large
> and daunting for newcomers. When alternatives for a given tool exist which are
> relevant and known outside the Debian eco system and there might be some
> practical use for learning those skills in other contexts, IMHO 
> Debian-specific
> solutions should need a strong argument *for* to keep, rather than *against* 
> to
> remove.
imho it is that range of development tools that make us strong. I packaged
for nearly every package system in the past and it is mainly the great eco
system of debian specific tools that make debian just a joy to package.

Alex


-- 
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/2028153930.ga11...@hawking.credativ.lan

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Goswin von Brederlow schrieb am Monday, den 28. November 2011:

> Alexander Wirt  writes:
> 
> > Jon Dowland schrieb am Montag, den 28. November 2011:
> >
> >> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> >> > And I still like the "never touch a running system" approach. If dpatch 
> >> > works
> >> > without problems, why deprecate it?
> >> 
> >> One reason is that the surface area of Debian development tools is too 
> >> large
> >> and daunting for newcomers. When alternatives for a given tool exist which 
> >> are
> >> relevant and known outside the Debian eco system and there might be some
> >> practical use for learning those skills in other contexts, IMHO 
> >> Debian-specific
> >> solutions should need a strong argument *for* to keep, rather than 
> >> *against* to
> >> remove.
> > imho it is that range of development tools that make us strong. I packaged
> > for nearly every package system in the past and it is mainly the great eco
> > system of debian specific tools that make debian just a joy to package.
> >
> > Alex
> 
> and then you need to fix a build failure somewhere deep down in cdbs. :)
such things happen and this may also happen for debhelper, dpkg, apt, and so
on.

Alex


-- 
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/2028201040.ga29...@smithers.snow-crash.org

Re: Lintian ERROR saying dpatch is obsolete

[Alexander Wirt]

Stefano Zacchiroli schrieb am Monday, den 28. November 2011:

> On Mon, Nov 28, 2011 at 12:54:57PM +0100, Alexander Wirt wrote:
> > Its simple and things like dpatch-edit-patch are just great. I now use 
> > dpatch
> > for round 8 years and it worked every time. I don't see any reason to move
> > away.
> > 
> > And I still like the "never touch a running system" approach. If dpatch 
> > works
> > without problems, why deprecate it?
> 
> Well, there is also the cost of diversity to take into account. I don't
> doubt that for you, right now, dpatch is better than quilt. You are used
> to it and you're happy with it. But in a project as large as Debian
> diversity has a cost.
> 
> Think about learning packaging (which is an important use case, given
> that we often lament we don't have enough people power in Debian). The
> cost of package learning is proportional to the number of tools
> involved. Multiplicating the number of tools that do the same thing adds
> up to that number, for anyone who has to deal with packages maintained
> by diverse teams with potentially different habits.
> 
> To name another use case, we have learned in the past release cycles
> that the only way to keep up with Debian releases is to have a
> significant number of people that do NMUs. Given that we need those
> people, we should also try to apply a principle of least surprise from
> one package to another. For the Squeeze release I've NMU-ed packages
> maintained in yada. Not. Fun.
> 
> The maintainer surely had the right to maintain them in yada, but that
> choice induced a cost on the release cycle of others who had to learn
> yada in the unfortunate case the maintainers stopped doing her job
> properly.
> 
> We have a tradition in Debian on standardizing on interfaces, which is
> good. But also standardizing on tools has value, because it reduces the
> cost of diversity throughout the archive. If standardizing on tools is
> considered to be too much, we should at least encourage uniformity.
> That, I believe, is what Gergely is doing, and I applaud the effort.
The question is: who decides? I have a bunch of packages and an established
workflow that served me well over the last years. I don't want to learn
another *censored* system, just because someone said its the new standard or
it is better. I can't remember that somebody asked about deprecating well
established and working tools.

Alex


-- 
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/2028224143.ga3...@smithers.snow-crash.org