Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy

[Joachim Breitner]

Hi,

Am Montag, den 01.11.2004, 10:58 +0100 schrieb Frank Küster:
>- a README.Debian-source file added to the orig.tar.gz 

I think this is should be done, or any other way that clearly marks
the .tar.gz as modified (even if only files are removed, it is a
modification). Anyone downloading a .orig.tar.gz file from debian should
be able to safely assume that it really is the "original .tar.gz". If
this for any reason is not right, there should be a note attached. The
most convenient way to do so is to include a file like this in the
tar.gz.

The problem of changes of this file is a true one. Therefore, maybe we
can agree on a standard wording for these file, something like:


This file was modified by the debian package maintainer in the following
way:
These files were removed:
rfc/12345.txt
bin/firmware.bin

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Joachim Breitner]

Hi,

Am Mittwoch, den 01.12.2004, 15:01 -0500 schrieb Rudy Godoy:
> El da 01/12/2004 a 06:28 Steve McIntyre escribio ...
> I completely agree on this, what is the reason/usefulness to have a cpu
> monitoring program which "main feature" is to show a naked woman (or
> man)? Since there are other programs which do the same? does it improves
> the distribution, user-friendlyness, encourages people to install
> Debian instead other distros? or ... helps to have Sarge released?

Well, maybe the user-friendlyness. I had a look (at the program, not
only the picures). The blending is pretty nice. Put aside the choise of
picutures, the program is worth having in debian as long as someone
maintains it. To the pictures - maybe we could avoid the problem by
making the thing theme-able, distribute a unproblematic version (e.g.
only down to the bikini) along some other nice pictures (sunrise, tree
loosing trees). The program could then offer a link to a website where
the user can easily download .tar.gz'ed themes which can be installed
using drag 'n drop - and everyone would be happy.

With regards,
nomeata
-- 
Joachim Breitner
  e-Mail: [EMAIL PROTECTED]
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Joachim Breitner]

Hi,

Am Freitag, den 03.12.2004, 22:55 -0600 schrieb Ron Johnson:
> On Sat, 2004-12-04 at 00:55 +1100, Russell Coker wrote:
> > On Thursday 02 December 2004 19:21, Ron Johnson <[EMAIL PROTECTED]> wrote:
> > We could have ftp.debian.XX (where XX is the country code) be a cname 
> > pointing 
> > to a server that only has packages that match the laws and standards of the 
> > country in question.  Someone in China, Iran, or the US can download from 
> > ftp.debian.nl at their own risk...
> 
> That's a good idea.  Someone else suggested using jigdo to customize
> CDs.

That might have been me. I also suggested using DebTags as the
categorizing mechanism for that.

(trying to get the discussion back to something productive)

regards,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor

[Joachim Breitner]

Hi,

Am Samstag, den 04.12.2004, 05:49 -0600 schrieb Ron Johnson:
> > That might have been me.
> It was Cesar Martinez Izquierdo.
Ok, so it was _also_ me :-)

> >  I also suggested using DebTags as the
> > categorizing mechanism for that.
> 
> Maybe the 2 could be used in concert?
> 
> Can jigdo be told, "grab everything except packages that have
> a certain tag?
That's what I meant. See
<[EMAIL PROTECTED]>, if you want.

> > (trying to get the discussion back to something productive)
> Silly man!
:-)

Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Bug#296448: ITP: poc -- MP3 streaming server and tools

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner <[EMAIL PROTECTED]>

* Package name: poc
  Version : 0.4.
  Upstream Author : Manuel Odendahl <[EMAIL PROTECTED]>
* URL : http://www.bl0rg.net/software/poc/
* License : BSD
  Description : MP3 streaming server and tools

poc is a suite of MP3 tools and MP3 streaming programs. It can stream
MP3s over HTTP, RTP (RFC 2250 and RFC 3119) and a special protocol to
enable the use of Forward Error Correction to protect the MP3 stream
against packet loss. It can also stream OGGs over HTTP.

In addition to the streaming programs, poc contains two MP3 tools:
mp3cue and mp3cut. mp3cue can cut a big MP3 file according to a
tracklisting contained in a .cue file. mp3cut can split and
concatenate MP3 files according to time slices given on the command
line.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10.otto
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Bug#347807: ITP: xara -- a vector drawing program

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner <[EMAIL PROTECTED]>

* Package name: xara
* URL : http://www.xaraxtreme.org/ 
* License : to be released as GPL
  Description : a vector drawing program

The makers of the long-around Windows XaraX vector drawing program are
working on a GPL'ed linux release, and I plan to package that for
debian. I already contacted the upstream authors, and they will happily
assist me.

If someone really wants to work on this two, I'm sure we can arrange
some co-maintainership.

Greetings,
Joachim

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.otto
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Prelimary Debian Packages

[Joachim Breitner]

Hi,

As promised, I worked on packaging XaraLX for debian. I have put a
simple package for debian unstable on
http://people.debian.org/~nomeata/xaralx/xaralx_0.svn20060223-1_i386.deb

Please not that the source package is not yet available, as the source
is not yet released.

Please report non-packaging bugs to the xaralx mailing list, other bugs
to me.

See also 
http://www.joachim-breitner.de/blog/archives/128-First-Prelimary-XaraLX-debian-package.html

Greetings,
Joachim

PS: I'll be offline the next week, so if it doesn't work for you, I
guess you'll have to wait. :-)
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


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

Re: Drop the minor release number

[Joachim Breitner]

Am Freitag, den 08.07.2005, 17:05 +0200 schrieb Eduard Bloch:
> There is really no reason for having a "minor release
> number after dot" in the Debian version, it justs leads people to
> pointless discussions like this one.
Well, your suggestion sounds pointless to me.

I like it though. Skip the point!

:-)

Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata



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

Debian Bug Subscription Feature

[Joachim Breitner]

Hi,

Something that I have been missing for along time is the posibility to
subscribe to single bugs in our bugtracking system. Two years ago, at
Oslo, I created a patch to debbugs that would add that feature, but due
to slow communication with the debbugs team and probably not enough
persistence on my side, this never made in into the debbugs package.

Today, I started this again, this time as an independant service, thus
enabling easier development and no risk for the crucial debbugs
infrastructure. It is currenlty in "first usable state with minimum
features". To use it, send a mail to [EMAIL PROTECTED]
with the bugnumer (and only the bug number, nothing else, not even a #)
in the Subject. From then on, you should get any mail on
[EMAIL PROTECTED] that concerns that bug.

There is currently no way to unsubscribe. Not too bad, since bugs tend
to be fixed someday, but certainly a TODO. Also, there is no
confirmation question, nothing to prevent you from recieving the same
mail twice. There is a Anti-Mailloop-Feature, I hope it works. Debian
Developers can have a look at the code on
gluck.debian.org:~nomeata/debsub/, comments and patches welcome. 

Greetings from Helsinki,

Joachim



-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


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

Debian Packages for XaraLX

[Joachim Breitner]

Hi everybody,

on http://people.debian.org/~nomeata/xaralx/, you can find debian source
and binary (i386) packages for XaraLX[1], the recently GPL-freed vector
drawing application. The packages are there for public review of both
the program itself and the packaging work.

Please note that until XaraLX can be uploaded to debian, two things have
to happen: The CDraw library (currently included as a binary) has to be
freed, and wxwidgets 2.6.3 has to be uploaded to debian.

The current package is built with version 2.6.1 of wxwidgets, which is
in Debian, but causes some slider problems.

Also, the current packages does not have any sensible build-depends yet.
I will figure them out later, but if you happen to compile it on your
machine, I'll be glad to accept hints that shorten my
trial-and-error-using-pbuilder time :-)

Also, there is no manpage for XaraLX yet. Debian requires a manpage for
every binary, so some short descriptive manpage should be created.
@XaraLX-developers: Are you going to do that some time? Then I can skip
that step.

The package description is not yet perfect. Currently, it contains too
much MarketSpeak, I'd prefer a more objective description. Suggestions
are very welcome.

Of course, any kind of comment, criticism and contribution is welcome.

Greetings,
Joachim

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

-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


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

Re: Bug#190302: Misusage of changelog!

[Joachim Breitner]

Hi,

Am Mon, 2003-05-26 um 17.15 schrieb Philipp Matthias Hahn:
> Or do you expect everbody to file duplicate bugs or subscribe to
> existing bugs ?

AFAIK you can't subscribe to single bugs (at least I was told that a few
month ago). But this is one thing I'd like to change at debcamp in
Oslo...

Joachim

-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Virus emails

[Joachim Breitner]

Hi,

Is there something similar for exim (woody version)? I don't care too
much about the incoming bandwidth, but more about the resources that the
spam and virus checks consume, especially during these spam virus waves.
So I could add a (hopefully) cheap check at MTA level to reject these
mails until the wave is over.

Joachim

Am Di, 2003-09-23 um 04.29 schrieb Graham Wilson:
> On Mon, Sep 22, 2003 at 04:53:16PM +0200, Matthias Urlichs wrote:
> > Hi, Mike Hommey wrote:
> > > helps catching 95%... But the bandwidth is still used... I'm still
> > > looking for a pure MTA solution...
> > 
> > A pure MTA solution would still need to scan the body and thus would still
> > eat your bandwidth.
> 
> i have postfix's body_checks setup to reject lines that match the
> following regular expression (this is the first line of the base64
> encoded virus):
> 
> /^TVqQAAME\/\/8AALgAQAAA$/
> 
> i'm not sure when postfix closes the connection, whether its after
> recieving a matching line, or after the client is done sending data. if
> the former though, this would be a good "pure" mta solution that doesn't
> conserve too much bandwidth.
> 
> as to effectiveness, i've blocked 664 messages since saturday afternoon.
> i still get some swen messages through, but they have had the virus
> stripped already, so the message is considerably smaller.
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#192101: We need gnucash in stable

[Joachim Breitner]

Hi,

sorry to bug you again, and for "escalating" this to debian-devel, but
something needs to be done. For those just joining us:

gnucash (the probably most complete wand fit-for-real-use financing
program in debian) is not in testing for sarge at all. While the package
works very well for all users that get a binary, it just does not build
on some architectures (arm, hppa, m68k, mips{,el}). The problem lies in
the deep of some guile test in the gnucash testsuite, and is somehow
related to a random generater. Anyway, the maintainer tried to fix it,
upstream worked on it, but nothing helped yet, and nothing probably
won't help - at least within the next few weeks.

I would argue that it would be the best for our users if we put gnucash
in testing on the arches it builds, and leave the others out until they
are fixed. This would 
 * give the majority (i386, powerpc, etc) of our future sarge users this
program
 * have most of our woody users still have gnucash in their debian when
they upgrade
 * is absolutely no worse for those on the failing architectures, since
they won't have gnucash either way
 * if we fix the problem, we can add more architectures (for the same
version) in a sarge-r1-release.

The problem is that http://www.debian.org/devel/testing.en.html states:
> 2. It must be compiled and up to date on all architectures it has
previously been compiled for in unstable;

So I am basically calling for an exception here.

with regards

nomeata

PS: I wonder: why is the architecture count compared to prior versions
in _unstable_, while the RC-Bug count is compared to the RC-Bug count of
the perior version in _testing_? Seems to be inconsequent. Why not have
the line say:
> 2. It must be compiled and up to date on all architectures it has
previously been compiled for in testing; ?

Am Di, den 16.09.2003 schrieb Joachim Breitner um 16:52:
> Am Di, 2003-09-16 um 16.33 schrieb James A. Treacy:
> > I tried this before the last release and the archive maintainers were
> > not receptive to the idea(**). If we can get the archive maintainers to
> > agree to this I am all for it.
> You mean before woody? Then maybe it was because there was a version
> available in testing (1.6.6), but now there is none. Otherwise I don't
> know what. Anyway, we should try to ask again. GnuCash ist quite
> important, and our problem is at least not a questions of Freeness,
> which are really tough to find a consensus sometimes.
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Which packages will hold up the release?

[Joachim Breitner]

Hi,

Am Do, den 02.10.2003 schrieb Peter Makholm um 12:38:
>  - Gnome
>  - KDE

I just wondered how far your understanding of these goes? Only the base
environment, or also those applications that don't really belong to -
for example - the official Gnome distribution, but are needed to make
the computer useful. I am thinking here of evolution, one of the
browsers (galeon or (better and) epiphany) and gnucash (which has a RC
bug. help. help. :-)). Don't know much about KDE, but I guess there are
also applications not belonging to "the" KDE, but still should go with
it.
Also, please include openoffice in this list. Your list certainly is
right, but it seems to overlook the normal office application user (or
the system administrator, that has to set up large quantities of boxes
for the normal office application user), so I tried to be his advocate
here. Of course, my additions still don't make the list complete.

Maybe the right way to do this is not to look at all the packages that
come to one's mind and think if they are "very important", but to look
at the different "use cases" that come to ones mind, and have a look at
what they need. Some that I think if are the office worker, the web
developer/master, the software developer (including the debian
developer, a very important user group to debian :-)), the one with the
responsibility for security, the designer, and so on. This might be the
best way to check how good we are in our aim to be the "universal OS".

nomeata

-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Which packages will hold up the release?

[Joachim Breitner]

Am Do, den 02.10.2003 schrieb Joachim Breitner um 16:55:
> I just wondered how far your understanding of these goes? 
Uh. Please don't get it wrong, and consider the .de in my mail address.
I am not at all saying that you don't understand something. Merely, I
wonder what you _meant_ by this. The excuse is hidden somewhere in the
German language, where you can ask "how someone understands something"
and actually mean "what do you mean by" or "how do you interpret".

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reformatted Ubuntu Patches Repository

[Joachim Breitner]

Hi,

brought to you by the Utnubu team (that is me, still waiting for more
members, hint hint :-)), is the a newly formatted repository of Ubuntu
patches.

On http://utnubu.alioth.debian.org/scottish/by_maint/ you will find a
directory for each maintainer with modified packages, inside directories
for the kind of change (changelog_only, control_only, large), and then a
directory for the change. This data is pulled from 
http://people.ubuntu.com/~scott/patches/ but not yet automatically (I
will automate this, but not sure if I will have time for that here).

This is meant as a more convenient way for Debian maintainers to look
for possible useful patches from Ubuntu.

Greetings,
Joachim Breitner
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata



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

Bug#333690: ITP: prefixsuffix -- gui application that renames batches of files

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner <[EMAIL PROTECTED]>

* Package name: prefixsuffix
  Version : 0.5.0+cvs.2005.06.18
  Upstream Author : Murray Cumming <[EMAIL PROTECTED]>
* URL : http://prefixsuffix.sourceforge.net/
* License : GPL
  Description : gui application that renames batches of files

 PrefixSuffix is a GUI application that renames batches of files by
 changing the beginning or end of their names.

This package is in ubutun and will be adadpted to Debian as soon as the
dependencies are installable again.

Joachim

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.otto
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Re: actively notifying users of removed packages

[Joachim Breitner]

Hi,

Am Dienstag, den 11.03.2008, 05:23 -0700 schrieb Karl Chen:
> Thoughts?  What have I missed?  Existing solutions or non-problem?
> How can we move towards implementing something like this?  What
> other ideas are there for dealing with disappearing packages?

A solution that’s possible without big changes would be a package
"removal-notifier" which contains a manual list of removed packages
(which needs to be maintained by someone of course) and can tell the
user about packages he has installed but that are on that list.

Not very elegant, but it would work and probably quite easy to
implement.

Just a quick idea,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#479440: ITP: funpidgin -- A pidgin fork

[Joachim Breitner]

Hi,

Am Montag, den 05.05.2008, 01:19 -0400 schrieb Kevin Mark:
> On Sun, May 04, 2008 at 11:28:40PM +0100, Ben Hutchings wrote:
> > On Sun, 2008-05-04 at 23:24 +0300, Mohammed Sameer wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Mohammed Sameer <[EMAIL PROTECTED]>
> > > 
> > > * Package name: funpidgin
> > >   Version : 2.4.1
> > >   Upstream Author : A lot. Can't be listed here!
> > > * URL : http://funpidgin.sourceforge.net
> > > * License : GPL
> > >   Programming Lang: C
> > >   Description : graphical multi-protocol instant messaging client 
> > > based on pidgin
> > > 
> > > Funpidgin is a graphical, modular Instant Messaging client capable of 
> > > using
> > > AIM/ICQ, Yahoo!, MSN, IRC, Jabber, Napster, Zephyr, Gadu-Gadu, Bonjour,
> > > Groupwise, Sametime, SILC, and SIMPLE all at once.
> > > It has all the features offered by pidgin plus:
> > > * "Entry area manual sizing" a plugin by that allows manual resizing of 
> > > the entry area.
> > > * An option to set the size of the buddy icons displayed in the chat 
> > > window.
> > > * An option to let the window manager place new windows.
> > > * Two different ways of seeing that your buddies are typing.
> > > * An optional send button for Tablet PC users.
> > 
> > Maybe you could wait to see whether this fork lasts, and adds some
> > *substantial* features, before adding it?
> > 
> > Ben.
> > 
> 
> my understanding is that this is a 'protest' fork made to add a feature
> that the upstream did not want(the resizing). So as long as the upstream
> resists, it should survive.

Could we, as the Debian distribution, not make the decision what variant
we want to distribute? We can take the useful patches from funpidgin, if
they are good, and add them to “our” pidgin. That might be the best for
our users and in the spirit of free software, although it might be bad
for our relationship with upstream pidgin.

In any case I suggest that the maintainers of pidgin and funpidgin try
to work together to keep the packages in debian compatible as possible,
e.g. when it comes to plugins and the like.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Paid help for DDs and Debian infrastructure?

[Joachim Breitner]

Hi,

Am Dienstag, den 28.07.2009, 11:17 +0200 schrieb Steffen Moeller:
>  * the web-pages team might possibly need more helping hands to implement 
> what they want
> to implement and/or to coordinate the translations etc .. so they could get 
> some more
> graphical skills in or .. they would need to know ...

WRT to graphical skills, wait for
https://penta.debconf.org/dc9_schedule/events/459.en.html

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#551386: Per-package link to upstreams bugtracker

[Joachim Breitner]

Package: bugs.debian.org
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

just an idea that occured to me right now when filing a bug against a
package where I already know that it’s an upstream bug, but I don’t want
to spend time finding out
 * where the upstream bugtracker is
 and
 * how to properly list all upstream bugs.

Therefore, I’d find it handy to have, on the header of the package’s bug
page a link "Search upstream bugtracker" that directly sends me to the
upstream bugtracker, ideally to a search request for all bugs affecting
this particular program/component.


Implementation-wise, this is probably best implemented via a new
control header, similar to Homepage, containing the URL. But of course
I’m open for other ideas.

Greetings,
Joachim

- -- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

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

iEYEARECAAYFAkraNtEACgkQ9ijrk0dDIGxmmQCfX0q7b2Huz0XYpaN3IWNLRheG
OLQAn1uhzqu2E4aveAAP3+ru6eg/LaRo
=cEsf
-END PGP SIGNATURE-



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

Re: Bug#551386: Per-package link to upstreams bugtracker

[Joachim Breitner]

Hi,

Am Montag, den 19.10.2009, 11:20 +0200 schrieb Olivier Berger:
> Le samedi 17 octobre 2009 à 23:27 +0200, Joachim Breitner a écrit :
> > just an idea that occured to me right now when filing a bug against a
> > package where I already know that it’s an upstream bug, but I don’t want
> > to spend time finding out
> >  * where the upstream bugtracker is
> >  and
> >  * how to properly list all upstream bugs.
> 
> Such information is already used by bts-link to track changes on remote
> bugs linked with the 'forwarded' tag from Debian bugs.
> 
> The sources of bts-link ('s configuration file) contain already a
> description of many bugtrackers of source packages.
> 
> More details at : http://bts-link.alioth.debian.org/
> 
> Hope this helps.

I thought about bts-link as well, of course, but there are some
differences in what is tried to achieve:

bts-link is
 * per-bug.
 * thus can and needs to handle different trackers per package
 * needs manual intervention once (by setting the forwarded field)
 * aim for high-level technical integration.

my proposal is
 * per-package
 * should be present and visible _before_ the user files a bug
 * aims not for technical integration, but just lowering the effort for 
   the user to check the upstream bug tracker first

Also, just specifying a simple URL somewhere in the Package file, the
copyright file or somewhere else is sufficiently simple to be actually
implemented :-)

Also note that the information, like Homepage, should be set and stored
in the package first, and not, for example, in a list in the BTS. The
information is everything but Debian-specific and will be valid even
downstream.


I guess this could just be tried out by having early adopters add
XBS-Upstream-BTS: http://bugzilla.gnome.org/...
to some of their packages’ debian/control, add support to
bugs.debian.org, and see how it goes. If it goes well, debian-policy can
be amended and the XBS- prefix dropped. If not, it was worth a try and
did not hurt :-)

@dons: What are your requirements until you will accept this feature on
bugs.d.o, in terms of number of packages or clear consensus on d-devel
or such or actual inclusion in the policy?

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

FP: dita-ot -- transforms DITA content (maps and topics) into deliverable formats

[Joachim Breitner]

Hi,

it seems that RFPs are not forwarded to d-devel any more, and that my
List-CC to debian-sgml did not work, so here is the RFP I just filed at
http://bugs.debian.org/555635


* Package name: dita-ot
  Version : 1.4.1
* URL : http://dita-ot.sourceforge.net/
* License : Apache License V2.0, Common Public License 1.0
  Programming Lang: Java
  Description : transforms DITA content (maps and topics) into
deliverable formats

Hi,

I’m looking into packaging serna (see RFP 535828). One of the
dependencies of serna is the DITA Open Toolkit. DITA is somewhat a
competitor to DocBook and I’m surprised that none of it is package for
Debian yet.

I think this package needs some skilled XML people to maintain, and I
don’t think I’m one. Therefore, I’m filing this RPF, hoping that someone
will pick it up.

Thanks,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#560178: ITP: unicode-screensaver -- screensaver displaying unicode characters

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I’m about to upload this to Debian:

* Package name: unicode-screensaver
  Version : 0.1
  Upstream Author : Joachim Breitner 
* URL : http://www.joachim-breitner.de/projects#unicode-screensaver
* License : MIT/X
  Programming Lang: C
  Description : screensaver displaying unicode characters

 The unicode-screensaver is a simple screensaver application that repeatedly
 randomly picks an unicode character and displays it in a very large font
 size together with its unicode code point and the character name.
 .
 It works with xscreensaver or gnome-screensaver.


Greetings,
Joachim

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

iEYEARECAAYFAksfqo4ACgkQ9ijrk0dDIGxZnQCeNRaMHnz6oOjxCx/nCV/l8GvZ
RnYAoKtBBdO48Jlc/0A1QOrI9B1Znmn6
=fCrJ
-END PGP SIGNATURE-



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

Re: Bug#560178: ITP: unicode-screensaver -- screensaver displaying unicode characters

[Joachim Breitner]

Hi,

Am Mittwoch, den 09.12.2009, 19:37 +0100 schrieb Andreas Tille:
> On Wed, Dec 09, 2009 at 02:48:00PM +0100, Joachim Breitner wrote:
> >  It works with xscreensaver or gnome-screensaver.
> 
> Did you found any trick how it works with xscreensaver? For myself the
> greatest showstopper for a perfect screensaver (at least for showing off
> to my non-Linux colleagues) is bug #237296.  How does
> unicode-screensaver work around this bug?

I use fontconfig and freetype to render the characters. xscreensaver
shuns extra dependencies like this, that’s why my hack will not enter
the official distribution.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#561688: ITP: turbotail -- drop-in replacement for tail, using FAM for following files

[Joachim Breitner]

Hi,

Am Samstag, den 19.12.2009, 17:24 +0100 schrieb Christian Dietrich:
> Package: wnpp
> Severity: wishlist
> Owner: Christian Dietrich 
> 
> 
> * Package name: turbotail
>   Version : 0.3
>   Upstream Author : Folkert van Heusden 
> * URL : http://www.vanheusden.com/turbotail/
> * License : GPL
>   Programming Lang: C
>   Description : drop-in replacement for tail, using FAM for following 
> files
> 
> turbotail provides almost all command line options as the normal tail
> from coreutils, but when following files with -f, it doesn't poll the
> file every second, but uses FAM to get informed about changes at the
> file.

what advantage does turbotail provide over inotail, which is in Debian:

“inotail is a replacement for the 'tail' program found in the base
installation of every Linux/UNIX system. It makes use of the inotify
infrastructure in recent versions of the Linux kernel to speed up
tailing files in the follow mode (the '-f' option). Standard tail polls
the file every second by default while inotail listens to special events
sent by the kernel through the inotify API to determine whether a file
needs to be reread.”

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

http://utnubu.alioth.debian.org/scottish/ still used?

[Joachim Breitner]

Hi,

I am wondering if anyone still uses the re-ordered ubuntu patches
provided by the Utnubu team at

http://utnubu.alioth.debian.org/scottish/ 

If nobody finds this useful, I’d probably do the alioth admins a favor
if I stop the cronjob. 

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Debian on the FreeRunner -- now official

[Joachim Breitner]

Dear OpenMoko community,

the FSO packaging team of the Debian project[1] is happy to announce
that we have started to provide installation procedures and packages
required to have your FreeRunner[2] run Debian-powered.

This means that you can use your favorite tools such as apt-get and the
other >20.000 packages on your FreeRunner, including the
freesmartphone.org[3] software stack. You can also develop applications
for your FreeRunner the “Debian way”.

To install Debian onto your MicroSD card, alongside your current Image
on the internal Flash, see the instructions at
http://wiki.debian.org/DebianOnFreeRunner
These will provide you with a minimal Debian installation plus
everything required to use zhone. From there on, you are free to modify
your system as you wish – with the full power and flexibility of the
Debian system.

Note that Debian does not try provide yet another software stack (or
“Distribution” in the OpenMoko slang) next to 2007.2, 2008.8 or FSO, but
rather an alternative base, comparable to OpenEmbedded[3]. We are
looking forward to also support other stacks such as the Stable Hybrid
Release[4], once they are ready for that.

All this is still very new and was created during at the DebConf 8 in
Mar de Plata since last week. This means that there are still bugs and
other things to improve. You are invited to join the development by
subscribing to the smartphone-standards[5] mailing list that the Debian
team shares with the FSO team. There is also a wiki page[6] with more
information on the pkg-fso team, including a TODO section.

I’d like to thank Jon “maddog” Hall from Koolu[7] for lending me an
additional device for installation tests, and all the other testers at
DebConf and elsewhere that helped us to remove at least some of the
bugs. But don’t worry – I’m sure there are some bugs left for you!

Please send replies and further discussion to the
smartphone-standards[5] mailing list, but note that you have to
subscribe to that list first.

Enjoy!
    Joachim Breitner
on behalf of the pkg-fso team:
Philipp Kern
Jan Lübbe
Luca Capello


[1] http://www.debian.org
[2] http://wiki.openmoko.org/wiki/Neo_FreeRunner
[3] http://wiki.openembedded.net/
[4] http://wiki.openmoko.org/wiki/Stable_Hybrid_Release
[5] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/smartphones-standards
[6] http://wiki.debian.org/pkg-fso
[7] http://www.koolu.com/


-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Debian on the FreeRunner -- now official

[Joachim Breitner]

Hi,

Am Freitag, den 15.08.2008, 14:37 -0300 schrieb Paul Wise:
> On Fri, Aug 15, 2008 at 1:04 PM, Joachim Breitner <[EMAIL PROTECTED]> wrote:
> 
> > the FSO packaging team of the Debian project[1] is happy to announce
> > that we have started to provide installation procedures and packages
> > required to have your FreeRunner[2] run Debian-powered.
> 
> Will you be moving the pkg-fso packages to Debian experimental or sid
> at some point?

Yes, this is expected once the next englightment snapshot is packages,
in about one or two weeks.

> 
> > To install Debian onto your MicroSD card, alongside your current Image
> > on the internal Flash, see the instructions at
> >http://wiki.debian.org/DebianOnFreeRunner
> 
> This wiki page should probably moved into the InstallingDebianOn namespace:
> 
> http://wiki.debian.org/InstallingDebianOn

Hmm, I think i meant to do that, but I was confused that this page
starts with „DebianOn is an effort..“. Anyways, the link is out and
published, or do you think it’s very important?

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Processing of haskell-x11-extras_0.4-1.1_i386.changes

[Joachim Breitner]

Hi,

I just got this message, and I don’t know what to do with it. I uploaded
haskell-x11-extras_0.4-1_i386.changes to NEW a while ago, and it’s still
there. Maybe some buildd? Or did someone try to sneak in a package?

Greetings,
Joachim

Am Samstag, den 20.10.2007, 00:22 + schrieb Archive Administrator:
> PGP/GnuPG signature check failed on haskell-x11-extras_0.4-1.1_i386.changes
> gpg: Signature made Sat Oct 20 00:17:43 2007 UTC using DSA key ID BF45DCE3
> gpg: Can't check signature: public key not found
> gpg: Signature made Sat Oct 20 00:17:43 2007 UTC using DSA key ID BF45DCE3
> gpg: Can't check signature: public key not found
> (Exit status 2)
> haskell-x11-extras_0.4-1.1_i386.changes has bad PGP/GnuPG signature!
> Removing haskell-x11-extras_0.4-1.1_i386.changes, but keeping its associated 
> files for now.
> 
> Greetings,
> 
>   Your Debian queue daemon
> 
-- 
Joachim "nomeata" Breitner
Debian Developer
  [EMAIL PROTECTED] | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: [EMAIL PROTECTED] | http://people.debian.org/~nomeata

Bug#459593: RFA: dmraid

[Joachim Breitner]

Package: wnpp
Severity: normal

Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of the more important packages maintained by us is dmraid, with very
few open bugs, a new version to be packaged and probably curcial to some
users. This needs a real maintainer, or a proper maintenance team, so if
you want to do it, please step up.

http://packages.qa.debian.org/d/dmraid.html

Greetings,
Joachim


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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#459596: RFA: gtimelog

[Joachim Breitner]

Package: wnpp
Severity: normal

Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of these packages is gtimelog. gtimelog provides a time tracking
application to allow the user to track what they work on during the day
and how long they spend doing it. It has some active users according to
popcon, and no bad open bugs. It would be nice if this package could
have a proper maintainer.

http://packages.qa.debian.org/g/gtimelog.html

Greetings and thanks,
Joachim

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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Bug#459597: RFA: timer-applet -- timer applet - a countdown timer applet for the GNOME panel

[Joachim Breitner]

Package: wnpp
Severity: normal


Hi everyone,

the utnubu team maintains a few packages, but it turned out be not a
good maintance team, so are want to give our packages away.

One of these packages is timer-applet

The package description is:
 Features include:
 .
  * Quickly set a time and the applet will notify you when time is up
  * Create presets for quick access to frequently-used times
  * Small and unobtrusive. Choose to either view the remaining time right in
the panel or hide it so you don't get distracted by the countdown.
  * Add multiple Timer Applets to the panel to have multiple timers running
simultaneously
  * User interface follows the GNOME Human Interface Guidelines

It has a few minor open bugs, and there is a new upstream version
waiting. According to popcon, about 200 people have it installed, but no
use numbers were generated. It would be nice if this finds a real
maintainer. It is probably suiteable for beginner maintainers as well.

Greetings and thanks,
Joachim

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

Kernel: Linux 2.6.23-1-686 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



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

Debian Packaging advancements

[Joachim Breitner]

[CC’ing debian-devel because this is partly a call for contributions :-]

Hi,

today, I continued in my quest to make a proper Debian package out of
Serna. For now, I ignored the issue of the convenience code copies in
the source code and focused on getting a properly buildable package. The
four really required 3rd party tarballs are shipped in debian/3rd.

http://git.nomeata.de/?p=serna.git;a=summary contains the current state.

I started to use git-dpm[1] for packaging. This means that my changes
against the upstream (which is SVN trunk, revision 139) is stored in
debian/patches:
http://git.nomeata.de/?p=serna.git;a=tree;f=debian/patches;hb=refs/heads/master
Some of those can probably applied to the SVN directory directly, such
as 0017-Working-exports.lst-even-if-list-is-empty.patch. The others
should be reviewd and improved – I’m not an experienced C++ hacker.
Especially the 64bit stuff is just a hack and needs to made working
generally.

The debian packages does not have build-dependencies yet. If someone
wants to help assemble the correct set of packages (using pbuilder and
trial’n’error, that would be appreciated).

The serna binary is installed into /usr/bin/, the rest is put
in /usr/lib/serna. The binary is compiled with rpath so that the bundles
libs can be put in /usr/lib/serna/lib. I tried hard to make serna accept
this, but the patch that I try to use does not seem to be sufficient.
Any comments welcome:
http://git.nomeata.de/?p=serna.git;a=blob;f=debian/patches/0020-Hardcode-usr-lib-serna-as-DataDir.patch;hb=HEAD

I also started to work on the debian/copyright file, which is naturally
a large beast. Again, help is appreciated:
http://git.nomeata.de/?p=serna.git;a=blob;f=debian/copyright;hb=HEAD

All in all I thought would have gotten further in one whole day, and
motivation is fading again. Contributions by others are a good way to
increase motivation again :-).

Good night,
Joachim

[2] http://git-dpm.alioth.debian.org/


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: git and quilt

[Joachim Breitner]

Hi,

Am Mittwoch, den 03.02.2010, 16:25 -0600 schrieb Matt Zagrabelny:
> I read through the git-buildpackage docs and also a HOWTO by Russ
> Allbery [1] regarding git and Debian packaging. I am wondering if those
> who use git to manage their source package development are also using
> the debian/patches mechanism for modifying the upstream tarball.

I found git-dpm  very nice.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: experimental buildd link gone?

[Joachim Breitner]

Hi,

Am Samstag, den 13.02.2010, 11:12 -0600 schrieb Steve M. Robbins:
> The "links" box of the PTS used to have a link to the experimental
> buildd logs.  I think I used it last week but today it is not
> there; c.f. http://packages.qa.debian.org/g/gmp.html
> 
> How can I see the logs?

it’s only visible if the PTS knows about an experimental version, which
is not (yet) the case for gmp.

Here is your link:
https://buildd.debian.org/status/package.php?p=gmp&suite=experimental

Gruß,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Bug#573605: ITP: libnss-gw-name -- nss module that names the current gateway’s IP address

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I programed this little helper and plan to upload it to Debian shortly.

* Package name: libnss-gw-name
  Version : 0.1-1
  Upstream Author : Joachim Breitner 
* URL : http://www.joachim-breitner.de/projects#libnss-gw-name
* License : GPL
  Programming Lang: C
  Description : nss module that names the current gateway’s IP address

This Name Service Switch (NSS) module resolves the name
“gateway.current” to the IP of the current default gateways of the
system. This allows easy access to router configuration and to check if
connectivity problems are local or not.


I don’t have much experience with either writing an NSS module nor with
using the libnl library, so I’d appreciate a quick review of the code at
http://git.nomeata.de/?p=libnss-gw-name.git, especially with regard to
the NSS return codes and proper releasing of nl resources.


Greetings,
Joachim


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

iEYEARECAAYFAkuaTocACgkQ9ijrk0dDIGzGOQCfUgEaV94avMtox4m82uPMCWgK
0SQAoI6FmG2MsVzAjCxsgCDCXE0XcfT/
=e1Nq
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100312142407.13100.48928.report...@kirk.ehbuehl.net

Bug#574692: ITP: haskell-ltk -- leksah tool kit

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: haskell-ltk
  Version : 0.8
  Upstream Author : Juergen "jutaro" Nicklisch-Franken 
* URL : http://www.leksah.org/
* License : GPL
  Programming Lang: Haskell
  Description : leksah tool kit

UI Framework used by leksah.

This is a dependency of leksah.

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

iEYEARECAAYFAkuklGMACgkQ9ijrk0dDIGxAAACg0yYT9ckvkACTjF7ZdfHErxOU
SP8AoKAsrvryRFywPore5cK0Yxc94LlW
=1L2I
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092451.3741.91296.report...@kirk.ehbuehl.net

Bug#574690: ITP: haddock-leksah -- a documentation-generation tool for Haskell libraries

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: haddock-leksah
  Version : 2.6.0
  Upstream Author : Juergen "jutaro" Nicklisch-Franken 
* URL : http://leksah.org/
* License : BSD3
  Programming Lang: Haskell
  Description : a documentation-generation tool for Haskell libraries

This is a copy of haddock, exporting more of the internal modules as a
library.

This is a dependency of leksah.

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

iEYEARECAAYFAkukk5MACgkQ9ijrk0dDIGy3jgCfaYjYvHV3uQvrnpdnUxoJblFT
kpQAnROueN1Hi1TXvqBfz038WaGei7f/
=WAdi
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092125.3094.63581.report...@kirk.ehbuehl.net

Bug#574693: ITP: haskell-leksah-server -- metadata collection for leksah

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: haskell-leksah-server
  Version : 0.8.0.2
  Upstream Author : Juergen "jutaro" Nicklisch-Franken 
* URL : http://leksah.org
* License : GPL
  Programming Lang: Haskell
  Description : metadata collection for leksah

leksah-server is a background server to offload the heavy work from the
leksah client.

This is a dependency of the leksah client.

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

iEYEARECAAYFAkuklGYACgkQ9ijrk0dDIGz7RACeP8P1QOzBW4+CtL7u0sjbzG3R
3r8An0Y/abED3Hl+IBth2GEFeKI85Yl5
=bQeI
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092454.3049.66615.report...@kirk.ehbuehl.net

Bug#574691: ITP: binary-shared -- sharing for the binary package

[Joachim Breitner]

Package: wnpp
Severity: wishlist
Owner: Joachim Breitner 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: binary-shared
  Version : 0.8
  Upstream Author : Juergen "jutaro" Nicklisch-Franken 
* URL : http://www.leksah.org/
* License : GPL
  Programming Lang: Haskell
  Description : sharing for the binary package

A variant of the haskell binary packages with support for sharing.

This is a dependency of leksah.

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

iEYEARECAAYFAkukk+sACgkQ9ijrk0dDIGwd5QCdE9h3DQ6UMuyzm88wooZXtJ9L
gzEAnA04LmbL+Iu565z3WBVVcj5QfzA1
=E3Pe
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100320092251.3300.25869.report...@kirk.ehbuehl.net

Re: libnss-myhostname instead of mangling /etc/hosts

[Joachim Breitner]

Hi joey,

Am Sonntag, den 13.06.2010, 10:59 -0400 schrieb Joey Hess:
> Joachim Breitner wrote:
> > Would this be something that could be used by default in Debian, maybe
> > for squeeze+1? 
> 
> You're suggesting making the package standard priority. This is not a
> decision within the purvue of the d-i team, really.

that’s of course a valid point. I’ll therefore move the suggestion to
d-devel. Here is my original mail again:

> at the moment, the Debian installer creates a /etc/hosts file
> containing the local host name¹, so that this name is resolvable even
> if not registered in the DNS. Unfortunately, this is a possible cause
> of problems when the user wants to change the hostname – he has to
> change it in /etc/hosts two.
> 
> Lennart Poetting’s libnss-myhostname² works around this issue. Instead
> of hard-coding the hostname in /etc/hosts, this nss module resolves
> the current local host to 127.0.1.1. It also works with ipv6.
> 
> Would this be something that could be used by default in Debian, maybe
> for squeeze+1? 
> 
> Pros:
>  * Renaming a host does not affect /etc/hosts.
>  * /etc/hosts is the same on all installation and can be made a
> regular static conffile shipped by some base package, instead of being
> created by netcfg during installation.
> 
> Cons:
>  * Another nss module that has to be loaded.
>  * More code involed in a very common procedure that might contain
> bugs (but these will eventually all be fixed, I assume).
> 
> 
> What do you think?


OTOH, maybe libnss-myshostname does not have to be priority standard.
Instead, /etc/hosts could be shipped without the local hostname and
packages that are known to require the hostname to be resolvable can
just depend on it. Advantage is that only installations that really
require the feature need to install the package. Disadvantage is that
the admin can not easily remove it and do the /etc/hosts setting
manually. Maybe a case for a Recommends?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: all twitter client should support OAuth before they will drop Basic Auth in August

[Joachim Breitner]

Hi,

Am Montag, den 28.06.2010, 23:40 +0900 schrieb Hideki Yamane:
>  As I reported in Bug#587420, all twitter client should support OAuth since 
> twitter
>  will discard basic auth. If they not, we should drop them from Squeeze 
> release.
> 
>  These lists are assumed to be affected packages (got with "apt-cache search 
> twitter").
> 
> 
> bisho: ? does it need?? (meego)
> bti: not yet?
> choqok: needs update. It should be newer than 0.9.80 (Bug#587420)
> gtwitter: not yet?
> gwibber: not yet, see https://bugs.launchpad.net/gwibber/+bug/381133
> libmojito0: ? does it need?? (meego)
> libnet-twitter-lite-perl: OK
> libnet-twitter-perl: OK
> libsocialweb0: ? does it need?? (meego)
> libtwitter-glib-1.0-0: not yet?
> libtwitter-ruby1.8: not yet?
> libtwitter-ruby1.9.1: not yet?
> pidgin-microblog: OK
> python-twitter: not yet, see
> http://code.google.com/p/python-twitter/issues/detail?id=65
> python-twyt: not yet?
> qwit: needs update. It should be newer than 1.1-beta.
> tircd: OK, see 
> http://code.google.com/p/tircd/issues/detail?id=72&can=1&q=oauth
> twitux: not yet?
> smuxi-engine-twitter: not yet, see http://projects.qnetp.net/issues/show/368

twidge: Probably OK (depends on haskell-hoauth)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#587918: libnss-myhostname: Please do not depend on both libc6 and libc6-amd64

[Joachim Breitner]

Hi Petter,

Am Freitag, den 02.07.2010, 19:28 +0200 schrieb Petter Reinholdtsen:
> Package: libnss-myhostname
> Version: 0.2.4
> 
> I ran into this problem using the DVD build of Debian Edu.  The
> package was uninstallable on i386 because it failed to find
> libc6-amd64 on the DVD..  The cause can be found on
> https://buildd.debian.org/fetch.cgi?pkg=libnss-myhostname;ver=0.2-4;arch=i386;stamp=1277126824>:
> 
>  Package: libnss-myhostname
>  Version: 0.2-4
>  Architecture: i386
>  Maintainer: Joachim Breitner 
>  Installed-Size: 84
>  Depends: libc6 (>= 2.1.3), libc6-amd64 (>= 2.2.5)
> 
> Why do the package depend on libc6-amd64?  Please change it to not
> need two different libc packages.

I am at the moment building all architecture variants provided by
gcc-multilib. This is useful for e.g. amd64 systems which also run some
i386 binaries. I’m not overly confident that I am doing it the right way
though – the additional dependencies show one problem.

Maybe d-devel can help me out here:

I am building a nss library (libnss-myhostname). As these are linked
into arbitrary programs, they should be provided in all architecture
variants of a given architecture – e.g. on amd64, a i386 version should
be available as well, otherwise 32bit applications would not work.

I found two variants to provide for this:

a) nss-mdns build besides libnss-mdns also a 32 bit variant package
lib32nss-mdns for amd64.

b) libnss-extrausers builds only one binary package, which contains all
variants for a given architecture.

The approach b has the advantage that all variants are available and the
user does not have to remember that he might want to run 32bit variants
and needs to install another package. The cost of this is the additional
dependency on the “other” libc6-* package, as noted by Petter in this
bug.

So, what is the “best” way?

Greetings,
Joachim



-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#587918: libnss-myhostname: Please do not depend on both libc6 and libc6-amd64

[Joachim Breitner]

Hi Bernhard,

Am Samstag, den 03.07.2010, 11:55 +0200 schrieb Bernhard R. Link:
> BTW: speaking about the different subarchitectures. Perhaps it would make
> sense to move the debian/rules code I've written for libnss-extrausers
> to some common file (perhaps in dpkg-dev or somewhere else),
> so it can be included instead and not every libnss package needs to be updated
> if something changes.
> 
> It currently looks like:
> [..]

I modified the code a bit as libnss-myhostname uses automake and I had
to pass the correct build and host flags to configure so that it knows
when it is crosscompiling:

http://git.nomeata.de/?p=libnss-myhostname.git;a=blob;f=debian/rules;hb=HEAD

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: RFH: How to compile swf files from source

[Joachim Breitner]

Hi,

Am Mittwoch, den 04.08.2010, 17:25 -0500 schrieb Peter Samuelson:
> [Peter Samuelson]
> > Source code is a means to an end.  The end is the ability of the end
> > user to customize the software.  If you get source code but no way to
> > build a new .swf file from it, this end is not served.
> 
> Also, I'm a proponent of the idea of always building our packages from
> source - just to make sure we actually _can_, thus preserving the
> principle above.  I think it is a valuable service to the end-user to
> express the build process using Build-Depends and debian/rules.  They
> don't need to say "OK, I fixed this bug or typo or whatever, now how do
> I recompile it?"  They don't need to wonder whether it's even
> _possible_ to rebuild what they've changed (without, for example, going
> out and buying some non-free tool).

there were also cases of code-genearting tools (gob2 in my case) where
the package was built from the generated .c files instead the .gob
source files, and it happened that the .gob files were incompatible with
gob2 as shipped by Debian (they used unreleased features). I wanted to
change the program and could not. This particular issue has been fixed
by now, though, but it makes clear why building from source is
important.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: mass bug filing: packages not installable on any architecture

[Joachim Breitner]

Hi Ralf,

Am Mittwoch, den 04.08.2010, 01:50 +0200 schrieb Ralf Treinen:
> http://edos.debian.net/edos-debcheck/results/unstable/latest/every/list.php

with magic-haskell-doc there has been a mistake during package rename.
I’ve brought up the issue on debian-haskell.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Buildd & binary-indep

[Joachim Breitner]

Hi,

Am Samstag, den 25.09.2010, 00:18 +0200 schrieb Adam Borowski:
> On Fri, Sep 24, 2010 at 11:55:32PM +0200, Stéphane Glondu wrote:
> > What about building this architecture:all package only in binary-indep?
> > Like in the attached patch... This way, the buildds won't try to build them.
> 
> > diff -u wordnet-3.0/debian/rules wordnet-3.0/debian/rules
> > -build/goldendict-wordnet:: goldendict-wordnet.dsl.dz 
> > goldendict-wordnet_abrv.dsl
> > +install/goldendict-wordnet:: goldendict-wordnet.dsl.dz 
> > goldendict-wordnet_abrv.dsl
> 
> Uhm, but shouldn't that massive multi-hour _building_ of data be in a
> "build" (specifically, "build-indep") target rather than "install"?

one would expect that it works this way, any many people before you were
surprised by this fact. The problem is that build-indep and build-arch
are not required targets, and there is no easy way of checking whether
they exist.

It was suggested to make these targets a requirement, but so far nobody
dared to push the issue:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218893


Maybe now, with the DEP process, this is something that could be
tackled? I for one would very much welcome such a change.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Buildd & binary-indep

[Joachim Breitner]

Hi,

Am Samstag, den 25.09.2010, 17:04 +0200 schrieb Adam Borowski:
> On Sat, Sep 25, 2010 at 03:03:51PM +0200, Joachim Breitner wrote:
> > > Uhm, but shouldn't that massive multi-hour _building_ of data be in a
> > > "build" (specifically, "build-indep") target rather than "install"?
> > 
> > one would expect that it works this way, any many people before you were
> > surprised by this fact. The problem is that build-indep and build-arch
> > are not required targets, and there is no easy way of checking whether
> > they exist.
> 
> Oh, right.  That's indeed nasty.
> 
> I've skimmed through discussions about this matter, and the problem seems to
> be that make does not provide a way to tell why it failed -- so it's not
> possible to tell if the "build-indep" target exists.
> 
> Except, make does give an unique error message.  It may differ in various
> versions of make or locales, but at least for GNU make (which we do require)
> it's always different from anything else that can go wrong.

I’m still not convinced why we could not (after a release) just make it
required, fix packages using cdbs or dh7 centrally, wait for half a year
(while filing bugs etc.), then make the the buildds start calling
build-indep and NMU the remaining failing packages.

But a script like yours could indeed help to reduce the fallout.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Buildd & binary-indep

[Joachim Breitner]

Am Sonntag, den 26.09.2010, 08:50 + schrieb Philipp Kern:
> On 2010-09-26, Reinhard Tartler  wrote:
> > On Sa, Sep 25, 2010 at 21:59:51 (CEST), James Vega wrote:
> >> No, it builds all the content for arch:all and non-arch:all, but only
> >> creates the non-arch:all binaries.  The issue is that there's currently
> >> no way for the buildds to say "Only build the non-arch:all content"
> >> since the only required build target is "build".
> > what's the problem with requiring the binary-arch target for all
> > packages in debian after squeeze release?
> 
> That's already required.  What's not required (yet?) is a build target that
> only builds arch:any or arch:all.

Let me rephrase Reinhard: 
what's the problem with requiring the build-arch and build-indep target
for all packages in debian after squeeze release?

Greetings,
Joachim
 


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#606449: ITP: cnagios -- terminal interface for viewing nagios host and service objects

[Joachim Breitner]

Hi Bernhard,

Am Donnerstag, den 09.12.2010, 12:03 +0100 schrieb Bernhard Hauser:
> Package: wnpp
> Severity: wishlist
> Owner: Bernhard Hauser 
> 
> * Package name: cnagios
>   Version : 0.27
>   Upstream Author : Steve Rader 
> * URL : ftp://noc.hep.wisc.edu/pub/src/cnagios/
> * License : LICENSE-File within the tar.gz-archive
>   Programming Lang: C, Perl
>   Description : terminal interface for viewing nagios host and service 
> objects
> 
> Cnagios is a full-screen terminal interface for viewing Nagios HOST
> and SERVICE objects, and the durations of their current states.  It's 
> lightning fast because it's written in C using the curses library.
> And it's super flexible because it uses the perl C library to shorten 
> and alter host, service and plugin output and filter the displayed 
> HOSTs or SERVICEs.

thanks contributing this package. I think the description could need
some rewording; it sounds more like advertising than an objective
description.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: binNMU for Arch: all packages.

[Joachim Breitner]

Hi,

Am Samstag, den 15.01.2011, 10:29 + schrieb Philipp Kern:
> On 2011-01-15, Marco Túlio Gontijo e Silva  wrote:
> > The best option to fix this issue I can see is if it was possible to do 
> > binNMUs
> > for Arch: all packages.  There are some options to workaround the fact that 
> > we
> > can't binNMUs Arch: all packages, which are: change the -doc package to 
> > Arch:
> > any; do sourceful uploads instead of binNMUs.  Both options are not ideal, 
> > but
> > I prefer the first, because sourceful uploads for a 200 package stack would
> > need a lot of work.
> 
> If the packages are team-maintained, nothing is stopping you from bumping the
> revision with dch and do a build, sign, upload cycle.  Indeed without 
> source-only
> uploads you need to build it once.  But that's scriptable.  (And you can even
> cache the key's passphrase through gpg-agent.)

it would be ok if we were allowed to do "dch; dpkg-buildpackage -d -S;
debrelease". But actually building these 200 package manually on ones
own workmachine, getting the order of building correct, installing
dependencies and so on, without actually changing the package and just
so that they are rebuild is quite a nuisance and thus a slight waste of
developer resources and motivation. The buildds handle this much better
due to BD-Uninstallable and not blocking someones’s laptop. And if there
were autosigning in place (it is not yet, right?), the amount of human
time required would drop to almost zero.

(I know that I’m not actually helping to solve the problem, but I want
to give a better picture of the work involved and how much the buildd
infrastructure is relied upon by the Haskell team – thanks for that!)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#611315: ITP: channel-server -- channel server for XMPP-based decentral social networking

[Joachim Breitner]

Hi Jonas,

Am Freitag, den 28.01.2011, 00:41 +0100 schrieb Jonas Smedegaard:
> Package: wnpp
> Severity: wishlist
> Owner: Jonas Smedegaard 
> 
> * Package name: channel-server
>   Version : 0.0.1
>   Upstream Author : Stephan Maka 
> * URL : https://github.com/astro/channel-server
> * License : Apache-2
>   Programming Lang: JavaScript
>   Description : channel server for XMPP-based decentral social networking
> 
>  Node is an event-based server-side JavaScript engine.
>  .
>  channel-server is an XMPP component implemented in Node.
>  .
>  Social network users who are concerned about privacy and censorship
>  want to run their own decentralized instances, yielding full control
>  over own data. channel-server is a building block for a bright future:
>  it exposes your data to the network, featuring access control and
>  real-time update notification.
>  .
>  The primary network protocol is Buddycloud Channels, an open federated
>  protocol from http://open.buddycloud.com/ .

I’d suggest to reword the 3rd paragraph a bit, it is too advertising for
a package description, and should be more objective. Especially given
that the package does not provide a decentralized social network, but
only a building block.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Upstart and sysvinit in packages - Policy needed

[Joachim Breitner]

Hi,

Am Montag, den 14.02.2011, 13:57 +0100 schrieb Petter Reinholdtsen:
> I believe we need to come up with a way where most or all package
> maintainers (perhaps those handling kernel events and early boot stuff
> should be expected) only need to maintain one boot setup for their
> package, and this boot setup should be used by all the different boot
> systems. 

a way like metainit? http://wiki.debian.org/MetaInit

The project died some two or three years ago and anyone is welcome to
try to revive it.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: GNOME 3 and panel applets

[Joachim Breitner]

Hi,

thanks for the heads-up.

Am Montag, den 14.02.2011, 18:17 +0100 schrieb Josselin Mouette:
>  3. Port your applet to GTK3 and the new D-Bus API. The bindings for
> Python and C# will probably not work either, so you might have
> to start with them. 

do you have some pointers to migration guides or similar?

Also, for link-monitor-applet, I need to find out whether gob2 needs to
be updated. But it seems that GTK-3 still uses GLib-2, so this might
work.

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Upstart and sysvinit in packages - Policy needed

[Joachim Breitner]

Hi,

Am Montag, den 14.02.2011, 15:38 +0100 schrieb Tollef Fog Heen:
> ]] Petter Reinholdtsen 
> 
> | I believe we need to come up with a way where most or all package
> | maintainers (perhaps those handling kernel events and early boot stuff
> | should be expected) only need to maintain one boot setup for their
> | package, and this boot setup should be used by all the different boot
> | systems.
> 
> That would mean limiting each init system to the limitations of the most
> limited init system, which would be a sad state of affairs.

Not so sad, considering that a large portion of init scripts do hardly
need anything more and become more robust if they are not scripts any
more, but declarative descriptions.

For the rest (early boot stuff, display manager, complex daemons), we’ll
just continue writing having hand-written boot scripts.

(I really think that much more in Debian should be declarative and thus
consistent and robust, instead of repeatedly hand-written. What Michael
Vogt say about maintainer scripts equally applies to init scripts:

Another important problem to tackle is to make maintainer
scripts more declarative. I triaged a lot of upgrade bug reports
(mostly in ubuntu though) and a lot of them are caused by
maintainer script failures. Worse is that depending on the error
its really hard for the user to solve the problem. There is also
a lot of code duplication. Having a central place that contains
well tested code to do these jobs would be more robust. Triggers
help us a lot here already, but I think there is still more room
for improvement.
(http://raphaelhertzog.com/2011/01/21/people-behind-debian-michael-vogt-synaptic-apt-developer/)


But then, I should rather be quiet. I tried following this road and did
not manage to push it enough (though not because it wasn’t possible,
rather due to lack of time and motivation).


Greetings,
Joachim

-- 
Joachim Breitner
  e-Mail: m...@joachim-breitner.de
  Homepage: http://www.joachim-breitner.de
  ICQ#: 74513189
  Jabber-ID: nome...@joachim-breitner.de

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: re buildd's resolver and package's build deps

[Joachim Breitner]

Hi,

Am Montag, den 28.02.2011, 19:12 + schrieb Roger Leigh:
> Agreed.  Note that we now support strict 'first-only' alternatives
> handling with the 'apt' and 'aptitude' resolvers.  See the notes for
> 0.60.0 and 0.60.1 pertaining to resolvers here:
> 
> http://git.debian.org/?p=buildd-tools/sbuild.git;a=blob;f=NEWS;h=f4576f0e3b3c0fcd66abcd93898697246b9a;hb=HEAD
> 
> We have made the alternative resolving configurable, so that you can
> use strict 'first only' or all alternatives.  It defaults to
> 'first only', which will give resolution almost entirely like the
> internal resolver.

I have a bit a bad feeling about not being able to use alternatives in
build-depends. For example at the moment, we are renaming a self-hosting
compiler package from ghc6 to ghc. Previously, the dependency has been
on "ghc6". Now it is "ghc | ghc6", at least for the transition period,
and it would be a shame if the buildds would (do?) not cope with that.

And before someone suggests to have one upload with a dependency on ghc6
and then the next on ghc only – this would be troublesome as the
compiler will not work immediately on all arches, and we really like to
improving the package with subsequent uploads while sorting out how to
get it to compile on problematic architectures.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: re buildd's resolver and package's build deps

[Joachim Breitner]

Hi,

Am Sonntag, den 06.03.2011, 16:41 +0100 schrieb Olaf van der Spek:
> On Sun, Mar 6, 2011 at 4:36 PM, Joachim Breitner  wrote:
> > I have a bit a bad feeling about not being able to use alternatives in
> > build-depends. For example at the moment, we are renaming a self-hosting
> > compiler package from ghc6 to ghc. Previously, the dependency has been
> > on "ghc6". Now it is "ghc | ghc6", at least for the transition period,
> > and it would be a shame if the buildds would (do?) not cope with that.
> 
> What about renaming the pkg, have the new one provide the old one and
> continue depending on the old name until the new name is widely
> available?

yes, I also thought about it, and would be a sufficient solution. But
besides the case in question I’d like to make the point that there might
be more valid use cases for alternatives in build-depends, and we are
losing flexibility here.


But I’m a bit late in this thread and don’t want to re-start the
discussion. I guess as long as there are work-arounds (such as the one
above) it’s ok.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

"epollCreate: unsupported operation" on buildd hosts

[Joachim Breitner]

Dear Devel list,

updating the GHC haskell compiler to the newest version in Debian is
causing surprisingly many problems. With one of those, I am totally at a
loss to understand it, especially as I cannot reproduce it.

Basically, the new GHC compiler uses the epoll system call where
available, which should be the case on all Linux kernels by now.
Building the compiler works fine (even though it is a two stage
process), but then using the compiler to build another package (which
might or might not be a new version of the compiler) fails with:
epollCreate: unsupported operation (Function not implemented)
e.g. in
https://buildd.debian.org/fetch.cgi?pkg=ghc&arch=i386&ver=7.0.2-2&stamp=1299583867&file=log&as=raw
or 
https://buildd.debian.org/fetch.cgi?pkg=haskell-transformers&arch=amd64&ver=0.2.2.0-1&stamp=1299522650&file=log&as=raw

On my machine and other developer’s machines, this is not reproducible.
Upstream is rightfully puzzled as well (“That's odd. Is it always
reproducible within a single machine? Linux (and Debian) should support
epoll just fine.”, http://hackage.haskell.org/trac/ghc/ticket/5005)

Does anyone here have a clue as to why the epoll system calls might fail
on buildd machines?

Thanks,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: "epollCreate: unsupported operation" on buildd hosts

[Joachim Breitner]

Hi,

Am Mittwoch, den 09.03.2011, 10:22 +0100 schrieb Julien Cristau:
> epoll_create1 was added in 2.6.27, afaict.  If that's what haskell is
> using, then it's not unexpected to have it fail on 2.6.26.

good shot, thanks!

From ./libraries/base/System/Event/EPoll.hsc: (this line does not start with 
">")

epollCreate :: IO EPollFd
epollCreate = do
  fd <- throwErrnoIfMinus1 "epollCreate" $
#if defined(HAVE_EPOLL_CREATE1)
c_epoll_create1 (#const EPOLL_CLOEXEC)
#else
c_epoll_create 256 -- argument is ignored
  setCloseOnExec fd
#endif
  let !epollFd' = EPollFd fd
  return epollFd'

#if defined(HAVE_EPOLL_CREATE1)
foreign import ccall unsafe "sys/epoll.h epoll_create1"
c_epoll_create1 :: CInt -> IO CInt
#else
foreign import ccall unsafe "sys/epoll.h epoll_create"
c_epoll_create :: CInt -> IO CInt
#endif


and in libraries/base/configure.ac:
AC_CHECK_FUNCS([epoll_create1 epoll_ctl eventfd kevent kevent64 kqueue poll])


So what is the conclusion? Do we need to disable the use of
epoll_create1 completely? Or is it actually so that the libc should map
uses of epoll_create1 to epoll_create? Or do we need to introduce
run-time checks as to whether epoll_create1 is available?



Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: new scripts and patches for devscripts

[Joachim Breitner]

Hi,

Am Freitag, den 11.03.2011, 09:58 + schrieb Neil Williams:
> On Thu, 10 Mar 2011 10:51:50 -0800
> Steve Langasek  wrote:
> 
> > On Thu, Mar 10, 2011 at 06:32:28PM +0100, Mehdi Dogguy wrote:
> > > >get-build-deps
> > 
> > > Is this an alias for "apt-get build-dep $1"?
> > 
> > No, it's a tool that's been long missing from a Debian as a standard
> > interface - "install the build-dependencies for the package in my current
> > directory".
> > 
> > This may not be the best implementation/name/semantics, but there's
> > definitely a gap to be closed there, as 'dpkg-checkbuilddeps' provides no
> > easy way to feed the missing package list to apt, and 'apt-get build-deps'
> > can't look at the local directory.
> 
> embuilddeps, part of the xapt package, can now be used for that -
> currently in unstable. It also does cross-dependencies, for such time
> as we still need those to be done via xapt and dpkg-cross. embuilddeps
> uses the Dpkg perl modules directly and passes the results to apt-get,
> optionally also passing the full list (not including packages you've
> already got installed) to xapt for processing via dpkg-cross. If you
> don't specify an architecture to embuilddeps, it will do just what you
> outlined.

There is also this in haskell-debian-utils, although not very widely
advocated:
  * apt-get-build-depends:
Tool which will parse the Build-Depends{-Indep} lines from debian/control
and apt-get install the required packages
see http://packages.debian.org/sid/haskell-debian-utils

Some more results from someone’s itch-scratching.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Quote: Debian and Democracy at Advocato.org

[Joachim Breitner]

Am Do, den 09.10.2003 schrieb Branden Robinson um 05:17:
> http://people.debian.org/~rene/exa-log-24-07-2003

Just wanted to thank rene for recording that, it was a interesting
reading for the evening, and certainly better than German TV. I
especially like these parts:

15:39  * Madkiss grins
15:39  * _rene_ joins Madkiss
15:39  * robster too
15:41  * Wile_E gets popcorn
15:53  * stockholm needs to do his laundry.

:-)

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Source only uploads?

[Joachim Breitner]

Hi,

what if we stick to our principle "the maintainer knows best" and
provide the infrastructure for source only uploads, but leave it to the
maintainer whether he wants to do so. Some here think buildd'ed packages
are better, some think their building the packages themselves is better.
So just the former one do so and see what is used more, what stands the
test. Eventually, we might agree on one or the other way, but there is
actually no need for that.

Compare it to the different ways of building a package (self-made
debian/rules, dh_helper, cdbs) - it's all about choice and preference.

with regards,

nomeata


Am Mi, den 15.10.2003 schrieb W. Borgert um 19:48:
> Hi,
> 
> a few days ago, I uploaded an emacs mode package (all) source only
> w/o problems to ftp-master.  Today, a source only upload was rejected.
> Why?  I think, we should get rid of binary uploads...
> 
> Cheers!
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Source only uploads?

[Joachim Breitner]

Hi,

Am So, den 19.10.2003 schrieb Andrew Suffield um 21:08:
> On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote:
> The proposal was "All packages should be built in an artificial
> environment of this form". I have pointed out that this is a
> braindamaged idea.

Well, any maintainer that uses packages from experimental should not
build their packages on these mixed systems. Therefore, they use chroots
or a similar thing (unless they can afford an extra box for building).
In any case, this is an artificial environment, constructed especially
for the purpose of building packages for debian. Thus, that is no way
better or worse than debian's buildd.

I hope this supports my proposal in the other mail :-)

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source

[Joachim Breitner]

Hi,

Am Mi, den 19.11.2003 schrieb Oliver Kurth um 21:28:
> See, the copyright holder has no problem if those files are distributed.
> They will not care. I can also reconfirm this by asking them. So the
> problem is if this can still comply with the DFSG. So the exception
> should be made by Debian.
But won't be made, and I guess it's no use discussing this way.

> If this is not possible, maybe one workaround could be to make the
> paxkage without the firmmware files, and put them elsewhere on the
> web. So like libdvdread does it.
Better this way: Ask Atmel whether they allow unmodified distribution
independent of the GPL (which does not work anyway), and then
a) put the whole package in non-free
or
b) put the .hex files in non-free and the rest of the driver in main, if
the driver code is any use without the .hex files.

 It looks as if everytime we can get rid of a good reason for
non-free (e.g. viable acroread alternatives), new reasons (firmware for
drivers) arise. Sigh.

nomeata
-- 
Joachim "nomeata" Breitner
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Bug#171693: ITP: wondershaper -- a script to set up QoS, mainly for home users

[Joachim Breitner]

Hello,

Am Mit, 2002-12-04 um 14.25 schrieb Joerg Friedrich:
> martin f krafft schrieb am Mittwoch, 04. Dezember 2002 um 13:08:46 +0100:
> > * Package name: wondershaper

> Please notice that the wondershaper has two scripts. First is cbq-based
> and the other htb-based. cbq is no longer developped, but tc from
> iproute does not support htb.
> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171277
> 
> Maybe you should wait until a new iproute has been uploaded.

It is quite easy to build a iproute with rhe right htb support (the one
in iproute in sid is too old). You can find one at
http://joachimbreitern.dyndns.org/debian which works qute well with
2.4.20-rc5 and exactly this wondershaper script.

I created it like a NMU, but sent it to the maintainer, since I'm not
yet a debian developer and it is not yet urgent (thought that changes as
soon as 2.4.20 hits sid). If someone wants to NMU it, go ahead.

MfG
Joachim
-- 
Joachim Breitner 
[EMAIL PROTECTED] | http://www.joachim-breitner.de
JabberID: [EMAIL PROTECTED] | ICQ UIN: 74513189
GPG-Keyid: 4743206C
Terrorists can take my live.
Only the government can take my freedom.


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Time to package simpleinit?

[Joachim Breitner]

Hi,

obviously debian sid is from now on capable of supporting several init
script schemes. Now I wonder if it is now possible to package R. Goochs
simpleinit [1]. But I have some questions:

 * Would that require replacing sysv-rc or sysvinit+sysv-rc? I think
R.Goochs /sbin/init is capable of replacing our /sbin/init, but we
actually only want to replace the way the startup scripts are handled.
 * The /etc/init.d/ scripts would need to add "need otherscript" (and
sometimes "provide something"). As I think it is a very bad idea to edit
these scripts in our post-install (and try to reedit them in
pre-remove)) one would have to file bugs agains packages with
/etc/init.d scripts. Will that be sucessfull? How cooperative will the
maintainers of these script be?
 * Is there even interest in simpleinit by others than me? I would also
need someone to ask if I have problems with sysvinit or similar, and I
would like to know who thinks he is capable of helping me? Are there
people that might help me when it comes to file bug against packages
with /etc/init.d scripts?

Thx for your attention

Joachim aka nomeata

[1] http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/

-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Time to package simpleinit?

[Joachim Breitner]

Hi Henrique,

It is good to see that there is actually work done on it. Obviously you
are more into the topic (and you are a debian developer), so It's up to
me to offer you help with that, not the other way around :-)

After reading through your paper (nice work), it looks to me as if the
the simpleinit's and similar scheme's advantage is "only" the way the
startup scripts, while /sbin/init does much more (SIGPWR, reexecuting
itselfe, spawning login programs). It would be bad if the user that
wants to use simpleinit or minit had to do without the advanced sysvinit
functionality.

So the right place (it seems to be) to implement the init scripts
handling would be /etc/init.d/rc and make our minit or simpleinit
packages compatible with sysvinit. Would that be possible? Would we
reimplement it in /bin/bash, or strip down the
non-init-script-handling-functionality of minit/simpleinit? How will the
communication between /sbin/init and the simpleinit/minit work? Or won't
that scheme work?

While the simpleinit approach works well with you proposal in Section
5.4.1, how would that work with minit? If the maintainer scripts
register the dependencies using update-rc, then there is a duplicity
(information to update-rc and /sbin/init-* scripts called in the
/etc/init.d/-scripts).

Joachim aka nomeata


Am Sam, 2003-04-26 um 22.28 schrieb Henrique de Moraes Holschuh:
> On Sat, 26 Apr 2003, Joachim Breitner wrote:
> >  * The /etc/init.d/ scripts would need to add "need otherscript" (and
> > sometimes "provide something"). As I think it is a very bad idea to edit
> > these scripts in our post-install (and try to reedit them in
> > pre-remove)) one would have to file bugs agains packages with
> > /etc/init.d scripts. Will that be sucessfull? How cooperative will the
> > maintainers of these script be?
> 
> Very, as long as it is done in a serious, generic way. I am willing to help
> you on this.  But first, please read
> http://people.debian.org/~hmh/debconf2/debconf2-initscripts-bkg.pdf
> 
> We have a lot of work ahead of us.  I took a halt on it because I lacked the
> time, but now that Miquel surfaced again and did the sysv split, we could
> continue designing the system.  I figure sysvinit and friends will have
> stabilized again in a more change-init-system-friendly way by the time we
> finish...
> 
> Once it is designed (a way to properly support the dynamic dependencies such
> as need and provide of simpleinit), we can start deploying it.
-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Time to package simpleinit?

[Joachim Breitner]

d that SuSE's init scripts system does
> this, while also providing full automatic dynamic dependency
> management, ala simpleinit.  I haven't had a chance to look at it, but
> everything I've heard about it makes it sound far better than
> simpleinit.
> 
>   - Ted
-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

DebConf 3 for New Maintainers

[Joachim Breitner]

Hi,

Hi, I tried this already on debian-mentors, but maybe the right persons are 
here:

I am considering going to DebConf 3. Now Oslo is not really close (I
live in southern germany), and being a High School student, I would have
to argue with my principal whether I may go or not during school time,
so it should be worth the money and effort.

Well enough introduction; my main question is: Would it make sense for
me to attend Debcamp. Maybe my idea about DebCamp is wrong, but it
sounds as if it is just a very large debian hacking session, so one
needs to have something to hack on, and something to hack with. Would I
find a task there, or should I make sure I have one beforehand? Do I
have to bring my own PC?

What are your experiences, and what would you suggest a debian (the
project, not the distro) newbie?

Joachim

-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: DebConf 3 for New Maintainers

[Joachim Breitner]

Hi,

Am Mit, 2003-05-14 um 14.22 schrieb Andreas Tille:
> On 14 May 2003, Joachim Breitner wrote:
> > I am considering going to DebConf 3. Now Oslo is not really close (I
> > live in southern germany), and being a High School student, I would have
> > to argue with my principal whether I may go or not during school time,
> > so it should be worth the money and effort.
> I doubt that you will get any better education than at Debcamp.  By the
> way what kind of school is it which has no holidays at this time?
Gymnasium in Baden-Würtemberg
(For our english-speakers: Gymnasium in German is not the gym, but a
kind of public High School)

> > Do I have to bring my own PC?
> I would recommend this.  When I was in Bordeaux in 2000 without my own Laptop
> it was much less fun. :-(  The educational effect decreases drastically!
Well, that sould definatly interesting. I just hope I manage to get a
laptop 'till then. Or would you think a zaurus with debian is sufficient
:-) (Actually, why not: One might allow me to ssh on his machine so I
can actually compile stuff *g*)

> > What are your experiences, and what would you suggest a debian (the
> > project, not the distro) newbie?
> If you know the distro you know the unsolved problems.  If you have trouble
> finding problems which might be solved I would volunteer to compile a
> list. ;-))
I think the problem is that for most bugs you need either very deep
knowledge of the program or of some language or (mostly) both. So if you
can't do "much" C, a lot of bug fixing is out of your reach. Well, maybe
I can find some bugs I can fix with perl or shell etc until then.

Joachim
-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
-- 
Joachim Breitner 
  e-Mail: [EMAIL PROTECTED] | Homepage: http://www.joachim-breitner.de
  JID: [EMAIL PROTECTED] | GPG-Keyid: 4743206C | ICQ#: 74513189
  Geekcode: GCS/IT/S d-- s++:- a--- C++ UL+++ P+++ !E W+++ N-- !W O? M?>+ V?
PS++ PE PGP++ t? 5? X- R+ tv- b++ DI+ D+ G e+>* h! z?
Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge.
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: "thanks" messages on mailing lists/bug reports

[Joachim Breitner]

Hi,

Am Freitag, den 27.06.2014, 15:45 +0200 schrieb Sven Bartscher:
> I recently started contributing to debian.
> Before that, most of my writing with people I don't know personally
> through the internet was on Stack Exchange.
> On Stack Exchange, messages that only consist of thanking people or
> agreement are not considered helpful.
> This in mind I'm very unsure if I should write messages like that to
> someone or if I should avoid them (to not annoy anyone with them), on
> Debian mailing lists or bug reports.
> 
> What is your experience with that?
> How do you feel if you read such messages?
> Maybe more important: How do you feel if you don't get such messages?

motivation is the most important and most scarce resource in a project
like Debian. With that in mind: If you you feel like thanking someone,
please do! And if you think they deserve the support publicly (which can
make a big difference when people are unsure whether their work is
appreciated, which is the case more often than not), then do it on the
mailing list or the bug report. Such a mail, although of little content,
has more value that most opinionated mails repeated stated on mailing
lists like this.

Also, most Debianer are (by necessity) trained to ignore mail that has
little information for them, so I wouldn’t worry about the “spammyness”
of such a mail.

Thanks for bringing this up!

Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)

[Joachim Breitner]

Hi,

Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> > Maybe a “gift” job for a Debian Contributor would be to put together
> > a “DD’s cheat card”, with infos about how to contact DSA, WB team,
> > etc. – nothing about the how-to of packaging, but about the orga‐
> > nisational things in Debian. Maybe also an excerpt of the most
> > relevant things from control@b.d.o, things like that, things which
> > a DD (or even DM) may need occasionally. Something to bookmark.
> 
> https://www.debian.org/intro/organization

not really helpful. It links to
https://buildd.debian.org/
from where no information about how to query for rebuilds can be found.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)

[Joachim Breitner]

Hi,

Am Montag, den 14.07.2014, 08:49 + schrieb Thorsten Glaser:
> Kibi wrote:
> >Joachim Breitner  (2014-07-13):
> >>Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> >> >> [10]https://www.debian.org/intro/organization
> >>not really helpful. It links to
> >> [11]https://buildd.debian.org/
> >> from where no information about how to query for rebuilds can be found.

>When  requesting  binNMUs  or  give-backs  (retries  after  a  failed 
> build), please use the format
>described at [161]http://release.debian.org/wanna-build.txt.

> tl;dr: Make [161] clearer on that the message is to humans and
> that the format is only to be included in it somewhere, and link
> to [161] from [10].

And if possible, also from [11], where I would expect it.

(In fact I know about the text file, but repeatedly forget where it was
and have trouble finding it.)

Thanks in advance!
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: DD's cheat card (was Re: Bug#754416: makefs: FTBFS on mips: Must set MACHINE_ARCH to one of mipseb or mipsel)

[Joachim Breitner]

Am Samstag, den 26.07.2014, 15:59 +0200 schrieb Philipp Kern:
> On Mon, Jul 14, 2014 at 10:58:59AM +0200, Joachim Breitner wrote:
> > Am Montag, den 14.07.2014, 08:49 + schrieb Thorsten Glaser:
> > > Kibi wrote:
> > > >Joachim Breitner  (2014-07-13):
> > > >>Am Sonntag, den 13.07.2014, 13:02 +0200 schrieb Cyril Brulebois:
> > > >> >> [10]https://www.debian.org/intro/organization
> > > >>not really helpful. It links to
> > > >> [11]https://buildd.debian.org/
> > > >> from where no information about how to query for rebuilds can be found.
> > 
> > >When  requesting  binNMUs  or  give-backs  (retries  after  a  failed 
> > > build), please use the format
> > >described at [161]http://release.debian.org/wanna-build.txt.
> > 
> > > tl;dr: Make [161] clearer on that the message is to humans and
> > > that the format is only to be included in it somewhere, and link
> > > to [161] from [10].
> > 
> > And if possible, also from [11], where I would expect it.
> > 
> > (In fact I know about the text file, but repeatedly forget where it was
> > and have trouble finding it.)
> 
> Done.

Thanks!

Greeting,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: Why is package X not in testing yet?

[Joachim Breitner]

Dear Pietro,


Am Montag, den 18.08.2014, 23:51 +0200 schrieb Pietro Abate:
> On 18/08/14 18:10, Sven Bartscher wrote:
> > If we have a package, which doesn't migrate to testing, we usually
> > check the "Why does package X not in testing yet?" page or the PTS.
> > Usually they do a great job in telling us why our package doesn't
> > migrate.
> > 
> > But sometimes you have packages, which have complicated dependencies,
> > that don't make it easy to tell why our package doesn't migrate.
> > Usually the PTS and "Why is package X not in testing yet?" fail at
> > those packages and don't give any useful explanation. For example look
> > at the page for haskell-hgettext[1].
> 
> you might want to have a look at comigrate [1] a tool designed to
> answer these kind of questions and provide explanations that are as
> compat as possible. For example for haskell-hgettext [2] . If you find
> it useful, I'm sure the authors would be happy to hear from you.

unfortunately, comigrate doesn’t cut it for our case. From the page for
haskell-hgettext, I get redirected to haskell-uniplate, and from there
to other packages, none of which are the real culprit. Sven’s tool has
an idea of what must migrate together (relying on britney’s autohinter)
and ignores, for example, any dependency problems that are among these
packages.

Nevertheless, thanks for the pointer to comigrate. I think it could make
use of more visibility. Maybe a link from the PTS, along with the links
to other explanation pages?

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: incoming.debian.org opens its doors to the public

[Joachim Breitner]

Hi,


Am Sonntag, den 17.08.2014, 00:07 +0200 schrieb Ansgar Burchardt:
> First, the archive used by buildds is now publically accessible in
> http://incoming.debian.org/debian-buildd/. This location provides access
> to all recently uploaded packages, split into individual suites, and
> provides the neccessary metadata for APT to verify the integrity of the
> published files. See [1] for details.

this is great! This will allow me to speed up Haskell transitions
considerably, because I can schedule binNMUs based on new builds faster.



I noticed that http://incoming.debian.org/debian-buildd/ is an overlay
like experimental: It contains just the added packages. Is there a tool
around that will take sid’s Packages (resp. Sources) file and merge the
buildd-sid package into it, removing upgraded packages? My tools expect
a single Package files, and before I implement the merge in my tools I’d
rather not re-invent the wheel.

I used to implement this as “keep-latest” in the wanna-build git repo¹,
but maybe there is a more official solution:
http://anonscm.debian.org/cgit/mirror/wanna-build.git/tree/bin/keep-latest

Thanks,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: Why is package X not in testing yet?

[Joachim Breitner]

Hi,


Am Dienstag, den 19.08.2014, 12:46 +0200 schrieb Sven Bartscher:
> That's a bit more tricky than it seems, due to limitations in wget.
> wget doesn't support the -N (only download if remote file if newer)
> together with -O. So if I rename them wget won't be able to check their
> timestamps.

You can use curl instead of wget; in one instance I am using
$ curl -R http://mirror.bm.debian.org/debian/dists/sid/main/source/Sources.gz \
   -z unstable-main-Sources.gz \
   -o unstable-main-Sources.gz

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: Proper notation for common licenses

[Joachim Breitner]

Hi,

FTWIW, the copyright format specification 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-field
explicitly states:

Use of a standard short name does not override the Debian Policy
requirement to include the full license text in
debian/copyright, nor any requirements in the license of the
work regarding reproduction of legal notices. This information
must still be included in the License field, either in a
stand-alone License paragraph or in the relevant files
paragraph.

(Although I find that unfortunate, and makes me much less motivated to
find out whether a license that looks like a BSD license is actually
one of them on the list, if I still have to include it in the file.)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: Punctuation characters in Debian packaging

[Joachim Breitner]

Hi,


Am Montag, den 03.11.2014, 15:40 + schrieb Ian Jackson:
> There are probably a lot of things missing.  If you know about some
> corner of Debian tooling which has exciting syntax, please add the
> information you have.

apt-get supports appending - to a package name in its argument to
install to remove it; should such uses be listed on
https://wiki.debian.org/Punctuation?

Also, is a package name ending in a - legal?.. Looks like they are,
according to the policy. I guess I can upload p-.-+-.- then soon :-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: Punctuation characters in Debian packaging

[Joachim Breitner]

Hi,


Am Dienstag, den 04.11.2014, 14:26 + schrieb Ian Jackson:
> Joachim Breitner writes ("Re: Punctuation characters in Debian packaging"):
> > Am Montag, den 03.11.2014, 15:40 + schrieb Ian Jackson:
> > > There are probably a lot of things missing.  If you know about some
> > > corner of Debian tooling which has exciting syntax, please add the
> > > information you have.
> > 
> > apt-get supports appending - to a package name in its argument to
> > install to remove it; should such uses be listed on
> > https://wiki.debian.org/Punctuation?
> 
> Um, please do list it but as `disputed' or `conflicting', because...
> 
> > Also, is a package name ending in a - legal?.. Looks like they are,
> > according to the policy. I guess I can upload p-.-+-.- then soon :-)
> 
> ... yes, trailing `-' is permitted in a package name.

right, the policy does not forbid it. 

But policy is supposed to document current practice, current practice is
not to have trailing - in package names, so we could simply adjust
policy to this practice, forbid package names to end with anything but a
character, a number or +, and avoid any problems in the future.

(I don’t care too much either way, though.)

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#677474: Substvars for Build-Depends in the .dsc file

[Joachim Breitner]

Package: dpkg-dev
Version: 1.16.4.2
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

Dear developers,

currently a Debian source package specifies its build dependencies in
debian/control; this information gets copied by dpkg-source to the .dsc
file. From there it reaches the Source file which is taken into account
by our infrastructure, e.g. the build daemons and tools like apt-get
build-dep. Therefore, the data in .dsc is the effective copy. 

I would like to see more flexibility in dpkg-source as to where the
effective build depends come from. My use case are (as you might guess)
Haskell packages. If you look at 
http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc
you see it has a very long list of build dependencies. If you’d compare
that to
http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
you’d see that the process of creating the build dependencies is a
mostly mechanical process and doing that manually is a waste of human
developer time and a source for mistakes (which lead to FTBFSes and
hence more waste in buildd and buildd admin time).

For binary dependencies, thia issue is solved already: Using substvars
we leave it to the build process to figure out the correct dependencies.
This has worked great so far. I would like to be able to do the same for
build dependencies.

Here is my suggestion: dpkg-source already supports substvars. What
needs to be added:
  * A dpkg-source option to enable all this, say
--enable-control-substvars (meant to go to
debian/source/options)
  * A way to pass the -T option to dpkg-source in
debian/source/options (currently not possible, although this is
not clearly documented)
  * When --enable-control-substvars option is enabled, dpkg-source
will call "debian/rules source-substvars" after "debian/rules
clean" and after creating the debian.tar.gz files, but before
creating the .dsc file¹
  * When creating the .dsc file, substvars specified in the file
specified in -T may be used in Build-Depends and related fields.

One downside is that dpkg-source cannot check the build dependencies
completely when calling debian/source clean, as it does now, but can
only check those that are given directly in debian/rules; at this stage
it should just ignore any substvars.

Comments?

Thanks,
Joachim

¹ Why at this stage? Calculating the precise build dependencies might
involve building the package. Doing it here allows this build to also be
used for creating the binaries, when doing a regular dpkg-buildpackage
build.

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

[Joachim Breitner]

Hi Bernd,

Am Donnerstag, den 14.06.2012, 10:32 +0200 schrieb Bernd Zeimetz:
> > I would like to see more flexibility in dpkg-source as to where the
> > effective build depends come from. My use case are (as you might guess)
> > Haskell packages. If you look at 
> > http://ftp.de.debian.org/debian/pool/main/h/haskell-yesod/haskell-yesod_1.0.1.6-1.dsc
> > you see it has a very long list of build dependencies. If you’d compare
> > that to
> > http://hackage.haskell.org/packages/archive/yesod/1.0.1.6/yesod.cabal 
> > you’d see that the process of creating the build dependencies is a
> > mostly mechanical process and doing that manually is a waste of human
> > developer time and a source for mistakes (which lead to FTBFSes and
> > hence more waste in buildd and buildd admin time).
> 
> Other peopel solve this by having a debian/control.in file and having
> - a debian/control target in debian/rules
> - having the clean target depend on debian/control.
> 
> I don't think that your case is special enough to add yet an extra
> option to dpkg-source. I have two packages where I'm changing much more
> than the build-dependencies automatically, for example.

I am aware of approaches using debian/control.in, but I was under the
impression that during the build, debian/control must not be changed and
hence this always requires manual interaction. If Updating
debian/control in the clean target, this is a large step in the right
direction.

The only problem I see with this is that if the build dependencies can
only be calculated after a full build, building source and binaries
requires two builds (and a third one if debuild -tc is used). (Maybe
less if debian/rules tracks the dependency of debian/control on *.cabal,
but I’m not sure how reliable this is in the when packing and unpacking
the sources.)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

[Joachim Breitner]

Hi,

Am Donnerstag, den 14.06.2012, 11:10 +0200 schrieb Bernd Zeimetz:
> > The only problem I see with this is that if the build dependencies can
> > only be calculated after a full build, building source and binaries
> > requires two builds (and a third one if debuild -tc is used). (Maybe
> > less if debian/rules tracks the dependency of debian/control on *.cabal,
> > but I’m not sure how reliable this is in the when packing and unpacking
> > the sources.)
> 
> Not knowing the build-dependencies before building the packjage
> sounds... WRONG. Whatever you do to figure them out, please do it before
> uploadfing it and trying to do this on a buildd :\

that’s not what I am saying I would (let my mycomputer) figure them out
before uploading, as they would appear in the .dsc file. I was assuming
the buildds use the information in the .dsc files to install the build
dependencies, but if I read Julien’s mail correctly, this is not the
case, so my approach would indeed fail.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#677474: Substvars for Build-Depends in the .dsc file

[Joachim Breitner]

Hi,

it seems that my idea is not well received; point taken, and I do like
the alternative about debian/rules creating debian/control in the clean
target.

Nevertheless :-)

Am Sonntag, den 17.06.2012, 13:39 +0200 schrieb Goswin von Brederlow:
> I think that the sources-subvars target must function without any
> Build-Depends-(Indep) installed because otherwise:
> 
> - Checking out the source from RCS or downloading the source leaves the
> source without full Build-Depends.

Getting it from source gives you the .dsc file, so you do have the
information. Getting it from RCS; well, that is not an official way for
Debian to distribute sources so it is up to the maintainers what comfort
level they’d provide.

> - Without Build-Depends the source can not be build.
> - Without build the sources-subvars can't be generated.
> 
> and you are stuck in a vicious circle.

Not so vicious if the missing build dependencies are obvious from
possible error messages: If the build process complains about haskell
library foo missing, you know you have to install libghc-foo-dev.

> Similar for a debian/control target in debian/rules. Although there you
> at least have the old Build-Depends to get you started.

Not if you follow the rule that no auto-generated file should live in
the VCS. As above, this is up to the maintainers to decide; cleanliness
of the repo vs. comfort for the check-outer.

> Overall I'm not sure the substvars would be better than a debian/control
> target.

I find generating debian/control somewhat of an hack (as it would be a
hack go generate it when creating binary dependencies), but not a bad
hack, hence I’m not reopening the bug.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Changes to Debian Maintainer upload permissions

[Joachim Breitner]

Hi,

Am Samstag, den 22.09.2012, 10:06 +0200 schrieb Ansgar Burchardt:
> During the FTPMaster meeting last week we have implemented the new
> interface for managing DM permissions[1].

very cool stuff, this makes DMs much more useful in teams with a large
amount of packages, thanks a lot!

Would it be possible to extend the syntax to specify lists of packages
not by name, but by Maintainer, e.g. pkg-haskell-maintainers@l.a.d.o?
Bonus points if such an assigment is expanded at dinstall time, so that
the statement “DM 1234 may upload all packages owned by this group”
stays up-to-date even if after new packages of this team have been
added?

(Of course this is just convenience and can already be achieved by a
small script that generates the list of packages.)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Changes to Debian Maintainer upload permissions

[Joachim Breitner]

Hi,

Am Sonntag, den 23.09.2012, 15:59 +0200 schrieb Joerg Jaspert:
> The DM flag (and in future ACL) shows that one trusts that one DM to do
> a good job on that one package. Extending it like "this DM may upload
> all packages of [whateverbiglist]" is just wrong.
> 
> > (Of course this is just convenience and can already be achieved by a
> > small script that generates the list of packages.)
> 
> Yeah, but please don't. Sillyness like "all of our team packages are
> always for all DMs of us" is really working against the system, IMO.
> If you want people to have upload rights for such large sets, make them
> DD. DM is for people interested in small(er) style maintenance.

I wouldn’t say it is plain wrong; there are certainly exceptions. All
(library )packages by the DHG have identical packaging issues – if
someone is able to do a good job on one of them, he is able to do a good
job of all of them. Also, the real time-consuming work for us is when we
need to upload all >450 packages with no source change, or a trivial
one. I am certainly looking forward to distribute the load not only on
the DDs but also on the DMs.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Changes to Debian Maintainer upload permissions

[Joachim Breitner]

Hi,

Am Montag, den 24.09.2012, 00:26 +0800 schrieb Thomas Goirand:
> On 09/23/2012 11:49 PM, Joachim Breitner wrote:
> > Also, the real time-consuming work for us is when we
> > need to upload all>450 packages with no source change, or a trivial
> > one.
> Someone assigned with such task as modifying (even trivially)
> and uploading 450 packages should definitively be(come) a DD.

I am not sure. Especially if the modifying is actually done before, in
the repo, reviewed by the team, maybe semi-automated across the packages
and all they are doing then is to manually build the packages in the
right order and upload them – I don’t see why a DM should be less
entitled to do so, or why we would want to have only DDs spend their
time on this tedious task.

(BTW, source only uploads anyone? Then I can easily do the uploads on my
own and need neither the DDs nor the DMs in my team to do what computers
can do better.)

That said, I am of course happy about every DHG-member that becomes a
DD.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Changes to Debian Maintainer upload permissions

[Joachim Breitner]

Hi,

Am Montag, den 24.09.2012, 11:59 -0500 schrieb Peter Samuelson:
> [Joachim Breitner]
> > Would it be possible to extend the syntax to specify lists of
> > packages not by name, but by Maintainer,
> > e.g. pkg-haskell-maintainers@l.a.d.o?  Bonus points if such an
> > assigment is expanded at dinstall time, so that the statement “DM
> > 1234 may upload all packages owned by this group” stays up-to-date
> > even if after new packages of this team have been added?
> 
> So ... you want to give a DM the ability to NMU any package in the
> archive, just by changing the Maintainer field?

Obviously the question whether a DM, who is allowed to upload packages
on behalf of pkg-haskell-maintainers@l.a.d.o, is allowed to upload
package X would depend on the maintainer field of the packages already
in Debian, not the one in the package he uploads. Just the way it is at
the moment with DMUA: A DM cannot just NMU an arbitrary package just by
setting the flag in the new package.

But thanks for asking, just in case this was not clear to others.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Why not to let all DDs to execute "gb"-command

[Joachim Breitner]

Hi,

Am Donnerstag, den 06.06.2013, 12:24 +0200 schrieb Philipp Kern:
> On Wed, Jun 05, 2013 at 09:10:39PM +0200, Anton Gladky wrote:
> > I think, most of developers are clever enough to define, whether the
> > built failed "accidentally" and needs to be restarted, or it requires
> > some fixing and uploading new version. It will save time for both DDs
> > and wb-team.
> 
> Generally I'd have liked that. Currently there's no proper scheme to
> authorize only that action (wb talks directly to the DB and does the
> changes). That said, many requests seem to be "let's retry that, maybe
> it doesn't fail" (for SIGSEGV/SIGBUS). The interface should at least
> encourage developers to think twice.

if the DPAs get wanna-build support (which I hope) you certainly don’t
want to handle nmu and gb requests for every developer’s pet
repositories, so there will be a need for a general interface. Can this
be done using dcut files, just as with other DPA management commands?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: AGPLv3 Compliance and Debian Users

[Joachim Breitner]

Hi,

Am Donnerstag, den 11.07.2013, 17:48 +0800 schrieb Paul Wise:
> On Thu, Jul 11, 2013 at 5:41 PM, Lars Meyser wrote:
> > This is also my personal reading of the license, I would like to hear others
> > opinions before I start filing bugs.
> 
> Perhaps you missed "if you modify the Program" in item "13. Remote
> Network Interaction;" of the AGPL?

nevertheless it would be good if AGPL programs in general, and
especially as packaged in Debian, would simply also install a tarball of
the (patched) sources and have a download link in the program, so that
the user has do not worry about this at all.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: AGPLv3 Compliance and Debian Users

[Joachim Breitner]

Hi,

Am Donnerstag, den 11.07.2013, 13:41 + schrieb Jeremy T. Bouse:
> I would find 
> having the Debian package install a tarball that could be linked to and 
> downloadable from the end user to be unnecessary duplication if all that 
> would be needed would be a link then why not just have that link point 
> to the source on the Debian mirror.

the question is: Does Debian guarantee (or at least promise) to provide
the sources for a sufficient amount of time _in the required version_?I
guess with http://snapshot.debian.org/ we do (and having AGPL software
in Debian include a link to there would already be very nice), but
having the source shipped with the package itself would solve a this
problems more elegantly, and would also work in a lonely-island-setting.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: On accepting pre-generated doc from upstream

[Joachim Breitner]

Hi,

Am Donnerstag, den 18.07.2013, 14:45 +0200 schrieb Goswin von Brederlow:
> On Thu, Jun 06, 2013 at 11:35:46PM -0300, Lisandro Damián Nicanor Pérez Meyer 
> wrote: 
> > - Using the full source tarball. Saddly this means having to compile most 
> > of 
> > it in order to get the tools for building the doc, or hacking far too much 
> > the 
> > build system to do something else.
> > 
> > - Build each submodule's doc.
> > 
> - Option 3:
> 
> For packages 1 and 2 build without docs but also build a
> package{1,2}-src package.

Option 4:

Have two source packages, package1 and package1-for-docs. They’d have
exactly the same upstream tarball, but of course different debian/-dirs:
  * The first builds the binaries and no docs.
  * The second source package builds only the docs.
The gain is that the second source package can build-depend on package2
without introducing build dependency cycles. I’d say it justifies the
slight unprettiness of having the same tarball twice in the archive.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: asking for advice: all dependencies incl. version numbers

[Joachim Breitner]

Dear Illes,

Am Donnerstag, den 22.08.2013, 17:47 +0200 schrieb FARKAS, Illes:

> This is a researcher asking for advice.
> 
> 
> I'd like to download/parse for each version of each debian package
> which other package versions it depends on. 
> 
> 
> Do you think this information available in managable formats?

It is all in the Packages file, e.g.
ftp://ftp.de.debian.org/debian/dists/unstable/main/binary-amd64/Packages.bz2

It is a simple text file format and there are parsing libraries for
various programming language around. If you are more specific about your
goals and needs, I can give more specific advise.

> Have you seen similar work before?

The researches at IRILL have done lots of work on Package relationsships
and also created useful tools to investigate that. I don’t have a good
entry page to send you to, but I guess http://www.mancoosi.org/edos/ and
http://www.mancoosi.org/ are of relevance.

Greetings,
Joachim


-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata




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

Re: Bug#646804: ITP: cheermeup -- Send affirmative messages to the user via the notification library

[Joachim Breitner]

Hi,

Am Donnerstag, den 27.10.2011, 20:43 +0200 schrieb Enrico Zini:
> On Thu, Oct 27, 2011 at 04:07:57PM +, Thomas Thurman wrote:
> > In case it helps anyone's decision, I think the list of affirmative 
> > messages is short enough to
> > include here:
> > 
> > It is okay to express your needs and feelings.
> [...]
> > You've made people happy.
> 
> WHAT? You mean it doesn't have polygen integration?
> 
> How dare they make something like this without using polygen!

And then have
„It is okay to express happy people?“
Cool!

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: [Pkg-scala-maint] Binary blobs in source packages

[Joachim Breitner]

Hi,

Am Dienstag, den 13.12.2011, 19:29 +0100 schrieb Mehdi Dogguy:
> You mean having a circular build-dependency? That isn't great :/
> I've seen some packages doing that (don't recall which right now) but
> didn't like it, tbh. 

ghc does, for instance.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: [Pkg-scala-maint] Binary blobs in source packages

[Joachim Breitner]

Hi,

Am Mittwoch, den 14.12.2011, 17:44 + schrieb Wookey:
> I anyone is aware of packages where it really isn't possible to do an
> automatic bootstrap without a circular dependency (for the initial
> bootstrap build), I would like to know about it. 

again, GHC comes to mind. When I ported it to s390x, I had to use an old
version (6.4.2), find some 64bit patches that were used by someone to
port it to powerpc64 (https://slyfox.ath.cx/ghc/patches/6.4.2/) and
built it partly on s390, copied the generated C files, and then finished
the build on s390x. Then I used that to build 6.10.1, working around a
bug by manually building one file of the compiler without optimization.
And then I build 7.0.4 (the current version) using that file.

Certainly not something that is worth automating...

If you get the impression that upstream does not care too much about
exotic architectures – then you are right. Unfortunately, that is
nothing that we can change easily.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: many packages fail to build twice in a row again

[Joachim Breitner]

Hi,

Am Dienstag, den 20.12.2011, 21:36 +0100 schrieb Lucas Nussbaum:
> On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote:
> > With recent dpkg(-source) changes, many packages are again failing to
> > build twice in a row, because of uncommitted upstream changes.  Fixing
> > this was a lenny release goal, maybe it should be one again?!?  Most
> > importantly, maybe someone who has access to one of those build grids
> > can run the old tests again, because I feel by accidentally stumbling
> > upon these problems we will not be able to find and fix many of them any
> > time soon.
> 
> Is it really worth it? There are many ways to work-around this, such as
> using a temporary git repo to be able to 'git clean' and return to a
> clean state before each build.

I also find this a worthy goal. It is not always forseeable that a
package will be affected, so if you forget to prepare (e.g. by creating
a git repo), you can easily get into a situation where your changes are
entangled with a bunch of non-intentional changes that are hard to fix
manually and I’ve had to restart from scratch and manually picking my
changes from the large diff a few times.

I, for one, welcome new FTBTIAR bugs :-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Re: Bug#636679: ITP: apitrace -- tool for debugging OpenGL applications and drivers

[Joachim Breitner]

Hi,

Am Montag, den 26.12.2011, 07:12 +0100 schrieb Cyril Brulebois:
> Joachim Breitner  (05/08/2011):
> > sounds very interesting. But I wonder if the name could be a bit more
> > specific, like opengl-trace or graphics-api-trace, as it does not seem
> > to trace arbitrary APIs.
> 
> Currently I see:
> | Source: apitrace
> | Package: apitrace-gl-tracer
> | Package: apitrace-gl-retracer
> 
> does that look OK enough?

I’d probably have chosen the Source name to also include GL, but thats
almost bikeshedding, so OK from my POV.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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

Source package without a binary

[Joachim Breitner]

Dear devel,

I have an interesting case for a hypothetical „source package without
binary packages“: The haskell compiler comes with an extensive test
suite. This test suite
 1. is distributed separately from the sources,
 2. takes a long time to run and
 3. partly depends on libraries that do not come with the compiler
packages, and which in turn Build-Depend on the compiler.

Now point 1 could be solved with dpkg’s multi-tarball-feature, and point
2 is also somewhat minor (but not irrelevant, compiling GHC already
takes more than a day on weak architectures, delaying this further is
undesireable), but point 3 clearly prevents running the test suite
during the build of the GHC package itself.

From my point of view, it seems desirable to package the testsuite as a
source-package of its own, build-depending on GHC and the additional
libraries required, and upload that. Our autobuilding infrastructure
would thus run the testsuite on the various architectures, which is very
desirable, given that we are talking about a compiler that is not
well-tested by upstream on the more exotic architectures.

Theoretically, there is no interesting binary package produced from this
source package and it seems that the policy does not explicitly require
that a source package produces binary packages... but I am certain that
this is an assumption buried deep within so many parts of our
infrastructure that it is not a good idea to actually try this.

So the logical conclusion is to build a binary package from the source
that contains nothing (or maybe a log of the test results) and clearly
states in its description that there is no point in installing this
binary package.

Is this something that we want to allow? If not, how else should I
proceed? And are there developers who think that having a source package
without binary package is a good way to stress-test our infrastructure
for corner-case-bugs? :-)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata


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