Re: Upcoming FTPMaster meeting

[Raphael Hertzog]

On Sat, 12 Feb 2011, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2011-02-11 at 11:33:10 +0800, Paul Wise wrote:
> > On Fri, Feb 11, 2011 at 5:58 AM, Ben Hutchings  wrote:
> > > Since there is no support for auto-building arch-independent binaries
> > 
> > I would hope that throwing away developer built debs would also apply
> > to arch-independent packages, IIRC that was part of the proposal.
> > There was talk of a Build-Architecture field for Architecture: all
> > stuff that can only be built on certain architectures (firmware,
> > bootloaders etc where there is no cross-compiler available).
> 
> Using Build-Architecture would be a workaround, it should not be
> needed once multiarch is in place and those packages are built for
> their respective architectures.

While technically true, this can be discussed. I can imagine that you
might not want to configure multiarch on your system just because you
need some bootloaders files (e.g. syslinux-common in a CD build process).

Using multi-arch to solve this problem means changing the package from
arch: all to arch: i386 (or the specific arch set that you're interested
in).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
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/20110214073921.ge4...@rivendell.home.ouaza.com

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Raphael Geissert]

Charles Plessy wrote:
> 
> I would be happy to get build logs as well, or at least a link to an URL
> where they are dowloadable withouth HTML processing.

You can always | html2text -utf8

> For the moment, I only found raw logs in /srv/buildd.debian.org/db on
> buildd.debian.org, but that directory is not served over HTTP, so this
> excludes non-DDs for raw retrieval. (I am also wondering where to find the
> cryptographic signatures, but this is orthogonal to this discussion).

What signatures?

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ijac3v$utv$1...@dough.gmane.org

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Charles Plessy]

Le Sun, Feb 13, 2011 at 11:40:25PM +0100, Tollef Fog Heen a écrit :
> ]] Philipp Kern 
> 
> | Actually those build failures are nowadays sent to the PTS for further
> | distribution (the "buildd" keyword).  I don't know how many are subscribed
> | to those notifications, though.  (After all, they're not automatically
> | sent to the maintainer.)
> 
> Would people be opposed to changing that?  I would be quite happy to get
> mails if my packages FTBFS on various architectures, and I believe I'm
> competent to at least usually see if something fails because of
> something obvious or if it looks like a chroot/buildd issue.  FWIW,
> Ubuntu mails maintainers on build failures (at least in PPAs), and I've
> found that to work well.

I would be happy to get build logs as well, or at least a link to an URL
where they are dowloadable withouth HTML processing.

For the moment, I only found raw logs in /srv/buildd.debian.org/db on
buildd.debian.org, but that directory is not served over HTTP, so this excludes
non-DDs for raw retrieval. (I am also wondering where to find the cryptographic
signatures, but this is orthogonal to this discussion).

By the way, I have submitted the whishlist bug #605763 to ask if it were
possible to have sbuild use reproducible file paths during build, to minimise
diffs between build logs. That might help to compare autobuilt and
locally-built packages, as suggested in
.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20110214042738.ga18...@merveille.plessy.net

Re: Cross-check autobuilt binary pkg with maintainer-provided pkg

[Raphael Geissert]

Henrique de Moraes Holschuh wrote:
> This is a good reason to forbid source-only uploads, but there is another,
> which actually leverages what we do now, and the idea of not using the
> maintainer-provided binary packages in order to have better determinism on
> the build:
[...]

Sounds like a great idea, yes.
If ftpmasters don't want dak to do all the work, a new service under the QA 
umbrella could be setup. Sending the original metadata to the QA host should 
be enough for it to check the package built by the buildds whenever it is 
uploaded to the archive.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ij9v9j$e2e$2...@dough.gmane.org

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Raphael Geissert]

Philipp Kern wrote:
> Actually those build failures are nowadays sent to the PTS for further
> distribution (the "buildd" keyword).  I don't know how many are subscribed
> to those notifications, though.  (After all, they're not automatically
> sent to the maintainer.)

Taking a look at the database it seems everyone in the summary tag was also 
subscribed to "buildd." Now that I think about it, I remember reading about 
doing that when the tag was introduced.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/ij9uun$e2e$1...@dough.gmane.org

Re: The future of m-a and dkms

[Patrick Matthäi]

Am 14.02.2011 00:12, schrieb Iustin Pop:
> On Sun, Feb 13, 2011 at 06:00:10PM -0500, Michael Gilbert wrote:
>> On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:
>>
>>> On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
 since we have got a stable release with dkms now, I am asking myself, if
 it is still necessary to support module-assistant.
 dkms is IMHO the better system and maintaining two different systems for
 kernel modules is a bit bloated.
>>> With dkms, can you also create packages of the modules?
>>>
>>> At least I found it always very useful, to create modules with m-a, or
>>> via make-kpkg, and provide them via local archives to all my Debian
>>> boxes. Can save quite some compilation time, and one doesn't need kernel
>>> header + build packages etc. on all nodes.
>>
>> Yes, there is the "mkdeb" command-line option, but I suppose that
>> doesn't get as much testing as it should.
> 
> With my sysadmin hat on, compilation on servers is a *very* big no-no,
> so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
> should stay in.

I find it useful, e.g. for several servers, running different kernel
versions.

> 
> I know that right now, when backporting stuff at work, we have to drop
> the DKMS stuff and write our own packaging since DKMS doesn't play
> nicely with multiple kernel versions, embedding the kernel *and* package
> version in the final module version, etc. Things might have changed
> recently, but last time I looked DKMS was only good for desktops, and
> not as a reliable package-building method.
> 
> Of course, I might have wrong information, so clarifications welcome.

I think the disadvantage of dkms is, that apt will fail, if the module
couldn't be built for one of the "n" installed kernel versions, because
the module is not compatible {anymore} with the kernel version.
This process could be enhanced, by dropping an notify to the user, that
module "x" failed to buit on kernel version "y" and you might found more
information at "z". But you have got the same problems with m-a, just
you don't have to execute m-a by yourself.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



signature.asc
Description: OpenPGP digital signature

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Tollef Fog Heen]

]] Felipe Sateler 

| On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:
| 
| > FWIW, Ubuntu mails maintainers on build failures (at least in PPAs),
| > and I've found that to work well.
| 
| AFAIK, that service also mails when the build was successful, leading
| to a lot of noise.

I don't think it mails on successful builds, but I could be
wrong. Anyway, making it only mail on failure would be a pretty trivial
thing to implement, I'd imagine.  Also making sure the metadata is
available in headers makes it easy to filter the mails, to /dev/null (or
opt out through some other mechanism) if so desired.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/877hd3frwj@qurzaw.varnish-software.com

Re: The future of m-a and dkms

[Iustin Pop]

On Sun, Feb 13, 2011 at 06:00:10PM -0500, Michael Gilbert wrote:
> On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:
> 
> > On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
> > > since we have got a stable release with dkms now, I am asking myself, if
> > > it is still necessary to support module-assistant.
> > > dkms is IMHO the better system and maintaining two different systems for
> > > kernel modules is a bit bloated.
> > With dkms, can you also create packages of the modules?
> > 
> > At least I found it always very useful, to create modules with m-a, or
> > via make-kpkg, and provide them via local archives to all my Debian
> > boxes. Can save quite some compilation time, and one doesn't need kernel
> > header + build packages etc. on all nodes.
> 
> Yes, there is the "mkdeb" command-line option, but I suppose that
> doesn't get as much testing as it should.

With my sysadmin hat on, compilation on servers is a *very* big no-no,
so if mkdeb doesn't work or if it doesn't provide nice modules, then m-a
should stay in.

I know that right now, when backporting stuff at work, we have to drop
the DKMS stuff and write our own packaging since DKMS doesn't play
nicely with multiple kernel versions, embedding the kernel *and* package
version in the final module version, etc. Things might have changed
recently, but last time I looked DKMS was only good for desktops, and
not as a reliable package-building method.

Of course, I might have wrong information, so clarifications welcome.

regards,
iustin


signature.asc
Description: Digital signature

Re: Should pam_unix log non-interactive sessions? [c...@taz.net.au: Bug#612382: pam, non-interactive-sessions, and pam_unix spamming the auth log]

[Tollef Fog Heen]

]] Steve Langasek 

| Hi folks,
| 
| I have a bug report objecting to pam_unix logging all PAM sessions,
| interactive and non-interactive alike, to syslog.  Should pam_unix be
| dropped from /etc/pam.d/common-session-noninteractive?  It's only after
| pam-auth-update started being used and common-session-noninteractive is
| split out that anyone mentioned this might be a problem; before that I
| assumed that having pam_unix log the session was the right thing to do.
| 
| Any other arguments for/against this logging?

I've found it useful to have the logging there, and it's easy enough to
turn off if you don't want it there.  (I'd love it if there was a way
for admins to have a local per-pam-module override file of the bits in
/usr/share/pam-configs, say you had /etc/pam-auth/override/libpam-mount
it would override /usr/share/pam-configs/libpam-mount.)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87bp2fh6n3@qurzaw.varnish-software.com

Bug#613306: ITP: portsmf -- Portable Standard Midi File Library

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: portsmf
  Version : 0.1~svn20101010
  Upstream Author : Roger B. Dannenberg
* URL : http://portmedia.sourceforge.net/
* License : Expat
  Programming Lang: C++
  Description : Portable Standard Midi File Library

 Portsmf is "Port Standard MIDI File", a cross-platform, C++ library for reading
 and writing Standard MIDI Files.
 .
 Features:
 .
  - input and output of Standard MIDI Files
  - data structures, classes, etc. for representing music data in memory
o sequence structure consisting of multiple tracks
o track structure consisting of multiple events
o events contain note and control data
o extensible attribute-value property lists
o tempo track and time signature representation
  - input and output of a text-based representation: Allegro files
  - extensive editing operations on sequences and tracks
  - conversion to/from binary buffers for archiving, undo/redo, etc.



-- 
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/20110213230656.1077.21059.reportbug@localhost6.localdomain6

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Sune Vuorela]

On 2011-02-13, Tollef Fog Heen  wrote:
> Would people be opposed to changing that?  I would be quite happy to get
> mails if my packages FTBFS on various architectures, and I believe I'm
> competent to at least usually see if something fails because of
> something obvious or if it looks like a chroot/buildd issue.  FWIW,

Can anyone provide a estimated number of 'real issues' (from mainatiner
pov) vs 'chroot/buildd/uninstallability issues' ?

/Sune


-- 
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/slrnilgoqe.rvp.nos...@sshway.ssh.pusling.com

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[gregor herrmann]

On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:

> Would people be opposed to changing that?  I would be quite happy to get
> mails if my packages FTBFS on various architectures, 

Agreed, getting mails with build logs (or pointers to them) for build
failures would be helpful IMO.


Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Element of Crime: Wenn der Winter kommt


signature.asc
Description: Digital signature

Re: The future of m-a and dkms

[Michael Gilbert]

On Sun, 13 Feb 2011 23:52:22 +0100 Christoph Anton Mitterer wrote:

> On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
> > since we have got a stable release with dkms now, I am asking myself, if
> > it is still necessary to support module-assistant.
> > dkms is IMHO the better system and maintaining two different systems for
> > kernel modules is a bit bloated.
> With dkms, can you also create packages of the modules?
> 
> At least I found it always very useful, to create modules with m-a, or
> via make-kpkg, and provide them via local archives to all my Debian
> boxes. Can save quite some compilation time, and one doesn't need kernel
> header + build packages etc. on all nodes.

Yes, there is the "mkdeb" command-line option, but I suppose that
doesn't get as much testing as it should.

Best wishes,
Mike


--
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/20110213180010.7463399d.michael.s.gilb...@gmail.com

Re: The future of m-a and dkms

[Patrick Matthäi]

Am 13.02.2011 23:52, schrieb Christoph Anton Mitterer:
> On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
>> since we have got a stable release with dkms now, I am asking myself, if
>> it is still necessary to support module-assistant.
>> dkms is IMHO the better system and maintaining two different systems for
>> kernel modules is a bit bloated.
> With dkms, can you also create packages of the modules?
> 
> At least I found it always very useful, to create modules with m-a, or
> via make-kpkg, and provide them via local archives to all my Debian
> boxes. Can save quite some compilation time, and one doesn't need kernel
> header + build packages etc. on all nodes.

You can still publish ready compiled module on the other nodes and I
don't think, that it is necessary to safe this little bit compile time
and extra space for the headers, to support m-a in the next releases.

Also with dkms this job could be done more automagic (especially with
new kernel versions).

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



signature.asc
Description: OpenPGP digital signature

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Felipe Sateler]

On Sun, 13 Feb 2011 23:40:25 +0100, Tollef Fog Heen wrote:

> ]] Philipp Kern
> 
> | Actually those build failures are nowadays sent to the PTS for further
> | distribution (the "buildd" keyword).  I don't know how many are
> subscribed | to those notifications, though.  (After all, they're not
> automatically | sent to the maintainer.)
> 
> Would people be opposed to changing that?  I would be quite happy to get
> mails if my packages FTBFS on various architectures, and I believe I'm
> competent to at least usually see if something fails because of
> something obvious or if it looks like a chroot/buildd issue.  FWIW,
> Ubuntu mails maintainers on build failures (at least in PPAs), and I've
> found that to work well.

AFAIK, that service also mails when the build was successful, leading to 
a lot of noise.



-- 
Saludos,
Felipe Sateler


-- 
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/ij9nif$gv8$1...@dough.gmane.org

Re: The future of m-a and dkms

[Christoph Anton Mitterer]

On Sun, 2011-02-13 at 23:21 +0100, Patrick Matthäi wrote:
> since we have got a stable release with dkms now, I am asking myself, if
> it is still necessary to support module-assistant.
> dkms is IMHO the better system and maintaining two different systems for
> kernel modules is a bit bloated.
With dkms, can you also create packages of the modules?

At least I found it always very useful, to create modules with m-a, or
via make-kpkg, and provide them via local archives to all my Debian
boxes. Can save quite some compilation time, and one doesn't need kernel
header + build packages etc. on all nodes.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Should pam_unix log non-interactive sessions? [c...@taz.net.au: Bug#612382: pam, non-interactive-sessions, and pam_unix spamming the auth log]

[Patrick Matthäi]

Am 13.02.2011 23:45, schrieb Steve Langasek:
> Hi folks,
> 
> I have a bug report objecting to pam_unix logging all PAM sessions,
> interactive and non-interactive alike, to syslog.  Should pam_unix be
> dropped from /etc/pam.d/common-session-noninteractive?  It's only after
> pam-auth-update started being used and common-session-noninteractive is
> split out that anyone mentioned this might be a problem; before that I
> assumed that having pam_unix log the session was the right thing to do.
> 
> Any other arguments for/against this logging?
> 
> On my systems, this affects atd, cron, and samba; conceptually it should
> also apply to services like imap, pop and ppp, but in practice these
> services haven't switched over to common-session-noninteractive at all yet.
> Any change to the pam_unix profile now would impact those services later, so
> if people expect syslogging of those sessions via pam_unix, we should
> determine that now.
> 

*We* need those logging on our machines per default and I don't think,
that we are the only one. Non-interactive sessions should still be logged.
Personaly I would wish, that I can see in auth.log, if it is
{non-}interactive or not, but that is not the topic of this thread.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



signature.asc
Description: OpenPGP digital signature

Re: Upcoming FTPMaster meeting

[Russ Allbery]

Adam Borowski  writes:

> For example, any package built on a system with nvidia's drivers will be
> built against them rather than mesa due to diversions, and will be
> unusable anywhere else.

This hasn't been the case for a while.  We fixed this in the NVIDIA
packages.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/8762sn4kl5@windlord.stanford.edu

Re: The future of m-a and dkms

[Patrick Matthäi]

Am 13.02.2011 23:39, schrieb Cyril Brulebois:
> That said, I'm no longer interested in maintaining m-a (lack of time
> is one thing, lack of interest is another, “upstream first” yet
> another).

Putting my fglrx maintainer hat on, I am also no longer interested in
supporting m-a, putting my server administrator job hat on, I am happy
that we have got dkms now.

dkms is more widley use (especially by commercial software products) and
so on we could reach a widley user- and developer-base.

I think it would be a nice release goal for wheezy, to get rid of m-a
and to migrate all related packages to dkms.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



signature.asc
Description: OpenPGP digital signature

Should pam_unix log non-interactive sessions? [c...@taz.net.au: Bug#612382: pam, non-interactive-sessions, and pam_unix spamming the auth log]

[Steve Langasek]

Hi folks,

I have a bug report objecting to pam_unix logging all PAM sessions,
interactive and non-interactive alike, to syslog.  Should pam_unix be
dropped from /etc/pam.d/common-session-noninteractive?  It's only after
pam-auth-update started being used and common-session-noninteractive is
split out that anyone mentioned this might be a problem; before that I
assumed that having pam_unix log the session was the right thing to do.

Any other arguments for/against this logging?

On my systems, this affects atd, cron, and samba; conceptually it should
also apply to services like imap, pop and ppp, but in practice these
services haven't switched over to common-session-noninteractive at all yet.
Any change to the pam_unix profile now would impact those services later, so
if people expect syslogging of those sessions via pam_unix, we should
determine that now.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

- Forwarded message from Craig Sanders  -

Date: Tue, 8 Feb 2011 16:27:40 +1100
From: Craig Sanders 
To: sub...@bugs.debian.org
Subject: Bug#612382: pam, non-interactive-sessions, and pam_unix spamming the
auth log
Resent-To: debian-bugs-d...@lists.debian.org
User-Agent: Mutt/1.5.20 (2009-06-14)

Package: libpam-runtime
Version: 1.1.1-6.1

is there any reason why /etc/pam.d/common-session-noninteractive should
load the pam_unix module? i.e. does it serve any useful purpose?

unless there's a good reason not to, i strongly recommend that pam_unix
should be disabled in common-session-noninteractive.


The man page for pam_unix says:

  "The session component of this module logs when a user logins or leave
   the system."

so it does nothing but spam the auth log every time cron runs something.
ditto for other non-interactive "logins". there's already too much noise
in the auth log...which makes it harder to spot things that really need
to be noticed.


i've commented it out on my systems with no ill-effects, but that means i
now no longer benefit pam-auth-update


craig

-- 
craig sanders 



- End forwarded message -


signature.asc
Description: Digital signature

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Tollef Fog Heen]

]] Philipp Kern 

| Actually those build failures are nowadays sent to the PTS for further
| distribution (the "buildd" keyword).  I don't know how many are subscribed
| to those notifications, though.  (After all, they're not automatically
| sent to the maintainer.)

Would people be opposed to changing that?  I would be quite happy to get
mails if my packages FTBFS on various architectures, and I believe I'm
competent to at least usually see if something fails because of
something obvious or if it looks like a chroot/buildd issue.  FWIW,
Ubuntu mails maintainers on build failures (at least in PPAs), and I've
found that to work well.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87fwrrh82u@qurzaw.varnish-software.com

Re: The future of m-a and dkms

[Cyril Brulebois]

Patrick Matthäi  (13/02/2011):
> since we have got a stable release with dkms now, I am asking
> myself, if it is still necessary to support module-assistant.
> 
> dkms is IMHO the better system and maintaining two different systems
> for kernel modules is a bit bloated.
> 
> I think there should be a decission for wheezy, how we should
> continue with it.

*MAYBE* you could put the maintainers in copy? (Eduard added.)

That said, I'm no longer interested in maintaining m-a (lack of time
is one thing, lack of interest is another, “upstream first” yet
another).

KiBi.


signature.asc
Description: Digital signature

Bug#613297: ITP: twitter4j -- A Java library for the Twitter API

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 


* Package name: twitter4j
  Version : 2.1.11
  Upstream Author : Yusuke Yamamoto 
* URL : http://www.twitter4j.org/
* License : BSD
  Programming Lang: Java
  Description : A Java library for the Twitter API

 Twitter4J is a Java library which aims at easy integration of the
 Twitter service inside Java applications.
 .
 It features :
  - a 100% pure Java implementation
  - Built-in OAuth support
  - Out-of-the-box GZip support


I'm packaging this library as a dependency for ReplicatorG (ITP #613210)



-- 
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/20110213221206.26346.64800.report...@poincare.crans.org

The future of m-a and dkms

[Patrick Matthäi]

Hello folk,

since we have got a stable release with dkms now, I am asking myself, if
it is still necessary to support module-assistant.
dkms is IMHO the better system and maintaining two different systems for
kernel modules is a bit bloated.

I think there should be a decission for wheezy, how we should continue
with it.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/



signature.asc
Description: OpenPGP digital signature

Bug#613293: ITP: svgsalamander -- SVG engine for Java

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 


* Package name: svgsalamander
  Version : 0.0+svn0088 (Unfortunately, no real release)
  Upstream Author : Mark McKay 
* URL : http://svgsalamander.java.net/
* License : LGPLv2 and BSD
  Programming Lang: Java
  Description : SVG engine for Java

 SVG Salamander is an SVG engine for Java that's designed to be small,
 fast, and allow programmers to use it with a minimum of fuss.
 .
 It's in particular targeted for making it easy to integrate SVG into
 Java games and making it much easier for artists to design 2D game
 content - from rich interactive menus to charts and graphcs to
 complex animations.

I'm packaging this library as a dependency for ReplicatorG (ITP #613210).



-- 
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/20110213220314.12460.90424.report...@poincare.crans.org

Re: Cross-check autobuilt binary pkg with maintainer-provided pkg

[Joey Hess]

Henrique de Moraes Holschuh wrote:
> 1. Instead of discarding upon upload the maintainer-provided binary uploads,
>we should first retain some interesting metadata[1] about it, and then
>discard.
> 
>* Packages that outright FTBFS won't get uploaded
> 
> 2. Autobuild all binary packages (determinism, clean chroot, etc)
> 
> 3. Compare the metadata on the autobuilt binary packages and the binary
>packages originally uploaded by the maintainer
> 
> 4. Notify of any important discrepancies (through PTS, *automated*):

Completely agree. 

File sizes won't 100% stable unfortunatly but the rest should be.

> [1] Where metadata means dumps of the information we might want in step (4),
> but could also be the entire binary package. Whatever is more practical.
> 
> Obviously, it should be discarded after a small while (one week? one
> month?).

Putting it in the .changes file seems to make the most sense?

-- 
see shy jo


signature.asc
Description: Digital signature

Cross-check autobuilt binary pkg with maintainer-provided pkg

[Henrique de Moraes Holschuh]

On Sun, 13 Feb 2011, brian m. carlson wrote:
> On Sun, Feb 13, 2011 at 06:00:11PM +, Lars Wirzenius wrote:
> > That's something I don't understand. If I upload a broken package, why
> > should it be the buildd admin's job to deal with it? Should not I get
> > notified of the error, and told to fix it?
> 
> I've seen packages that don't fail until the very end of the build.
> This can waste a lot of buildd time, especially on very large packages.
> So yes, as the maintainer, it may be your problem to fix, but failing to
> test packages that as a result fail on the buildds won't make the buildd
> admins very happy.

This is a good reason to forbid source-only uploads, but there is another,
which actually leverages what we do now, and the idea of not using the
maintainer-provided binary packages in order to have better determinism on
the build:

1. Instead of discarding upon upload the maintainer-provided binary uploads,
   we should first retain some interesting metadata[1] about it, and then
   discard.

   * Packages that outright FTBFS won't get uploaded

2. Autobuild all binary packages (determinism, clean chroot, etc)

3. Compare the metadata on the autobuilt binary packages and the binary
   packages originally uploaded by the maintainer

4. Notify of any important discrepancies (through PTS, *automated*):

   1. Changed dependencies
   2. Changed file names (new/missing)
   3. (large?) changes to file sizes
   4. Changed linking information
   ...

This can help with the build-conflicts issues, plus raise an alarm for the
maintainer about his building environment _or_ about something weird going
on with the autobuilder.

We are not adding any extra pain for any maintainers, they upload exactly
what they are already uploading today.  We are also not adding to the normal
operational workload of the autobuilder operators, as we are not increasing
the FTBFS probability, nor adding any non-automated steps.

[1] Where metadata means dumps of the information we might want in step (4),
but could also be the entire binary package. Whatever is more practical.

Obviously, it should be discarded after a small while (one week? one
month?).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
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/20110213194931.gb2...@khazad-dum.debian.net

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Philipp Kern]

On 2011-02-13, Lars Wirzenius  wrote:
> On su, 2011-02-13 at 19:13 +0100, Luk Claes wrote:
>> On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
>> > On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
>> >> I don;t think that is a good idea, there are way too many people not 
>> >> building
>> >> and testing their packages properly already, we don't want to give that 
>> >> work to
>> >> the buildd-admins...
>> > That's something I don't understand. If I upload a broken package, why
>> > should it be the buildd admin's job to deal with it? Should not I get
>> > notified of the error, and told to fix it?
>> I guess the notifying is what would become the buildd admin's job...
> Why is this a manual job, rather than automated?

Actually those build failures are nowadays sent to the PTS for further
distribution (the "buildd" keyword).  I don't know how many are subscribed
to those notifications, though.  (After all, they're not automatically
sent to the maintainer.)

>> If people want to not have to build and upload binary packages, they
>> would better invest their time in setting up a central service that
>> would build for them and would help in uploading succesful builds
>> instead of complaining about thrown away binary packages IMHO.
> I thought this was the purpose of the existing buildd network.

I agree with you.  I don't see much sense in having a separate set of trusted
machines.  (And I don't think it's easy to setup such infrastructure
currently and honestly sign the result as a user.)

But then I'm all for source-only uploads.  If somebody abuses them, they
could be dealt with separately.

Kind regards
Philipp Kern


-- 
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/slrnilgbnm.2m0.tr...@kelgar.0x539.de

/srv on alioth nearly full

[Dominic Hargreaves]

Submitted via the official support route at



but I thought it was worth mentioning here too, in case anyone was
thinking of uploading any data...:

/dev/sda2 394G  384G  2.0G 100% /srv

Cheers,
Dominic.

-- 
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)


-- 
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/20110213190117.gz4...@urchin.earth.li

Re: Upcoming FTPMaster meeting

[Samuel Thibault]

Samuel Thibault, le Sun 13 Feb 2011 19:51:07 +0100, a écrit :
> Michael Goetze, le Sun 13 Feb 2011 19:21:32 +0100, a écrit :
> > On 02/07/2011 12:10 AM, Svante Signell wrote:
> > >On 2011-02-03, Joerg Jaspert  wrote:
> > >>* get rid of hurd (or discuss this)
> > >
> > >Why? GNU/Hurd has made vast improvements during last year. Even the
> > >Debian installer is functional. Now, with support for VMs like qemu, xen
> > >and virtualbox, more people are showing interest in GNU/Hurd.
> > 
> > I note that for January 2011, hurd.git had 4 commits, adding 17 lines 
> > and removing 7. This seems representative of recent months, and activity 
> > levels on gnumach.git are similar.

Also, you should check git log a bit more.  Yes, I haven't had much time
to spend on the Hurd lately, focusing on the Squeeze release rather than
on the hurd-i386 port. Check out the log around this summer.

> > How exactly do you make "vast improvements" at this rate? It must be 
> > very high-level code...
> 
> It's not improvements in the hurd codebase, but other packages, like the
> debian installer.

Samuel


-- 
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/20110213190136.gk6...@const.famille.thibault.fr

Re: Upcoming FTPMaster meeting

[Samuel Thibault]

Michael Goetze, le Sun 13 Feb 2011 19:21:32 +0100, a écrit :
> On 02/07/2011 12:10 AM, Svante Signell wrote:
> >On 2011-02-03, Joerg Jaspert  wrote:
> >>* get rid of hurd (or discuss this)
> >
> >Why? GNU/Hurd has made vast improvements during last year. Even the
> >Debian installer is functional. Now, with support for VMs like qemu, xen
> >and virtualbox, more people are showing interest in GNU/Hurd.
> 
> I note that for January 2011, hurd.git had 4 commits, adding 17 lines 
> and removing 7. This seems representative of recent months, and activity 
> levels on gnumach.git are similar.
> 
> How exactly do you make "vast improvements" at this rate? It must be 
> very high-level code...

It's not improvements in the hurd codebase, but other packages, like the
debian installer.

Samuel


-- 
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/20110213185107.gj6...@const.famille.thibault.fr

Re: Upcoming FTPMaster meeting

[Michael Goetze]

On 02/07/2011 12:10 AM, Svante Signell wrote:

On 2011-02-03, Joerg Jaspert  wrote:

* get rid of hurd (or discuss this)


Why? GNU/Hurd has made vast improvements during last year. Even the
Debian installer is functional. Now, with support for VMs like qemu, xen
and virtualbox, more people are showing interest in GNU/Hurd.


I note that for January 2011, hurd.git had 4 commits, adding 17 lines 
and removing 7. This seems representative of recent months, and activity 
levels on gnumach.git are similar.


How exactly do you make "vast improvements" at this rate? It must be 
very high-level code...


Regards,
Michael


--
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/4d58212c.2070...@mgoetze.net

Re: Upcoming FTPMaster meeting

[Steve Langasek]

On Sun, Feb 13, 2011 at 06:46:22PM +0100, Stefano Zacchiroli wrote:
> On Sat, Feb 12, 2011 at 08:22:39PM +0100, Bernhard R. Link wrote:
> > * Don Armstrong  [110211 23:01]:
> > > 3) uniform, known build environments
> > I think is a major disadvantage of this suggestion.

> I'm unconvinced by your (implicit) argument that switching to an uniform
> build environment will make the current testing of packages built in
> "weird" environments any worse than the present situation.

> Package maintainers are already expected to upload packages built in
> clean environment.

> If they are not doing it, then we have a problem of best practices
> which are followed by the developer community.

No, best practice is to verify *that their packages build correctly in a
clean environment*.  The easiest and most reliable way to do that is by
doing the build in such a clean environment yourself and using that
build for the upload.  But it is wrong to say that we expect all uploaded
packages to have been built in a clean environment.  That's part of the
reason we have a Build-Conflicts field in the first place.

I am certainly not opposed to the current plans to do all builds on the
buildds, but let's not go rewriting history here.

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


-- 
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/20110213183839.gb24...@becquer.dodds.net

Re: Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Lars Wirzenius]

On su, 2011-02-13 at 19:13 +0100, Luk Claes wrote:
> On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
> > On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
> >> I don;t think that is a good idea, there are way too many people not 
> >> building
> >> and testing their packages properly already, we don't want to give that 
> >> work to
> >> the buildd-admins...
> > 
> > That's something I don't understand. If I upload a broken package, why
> > should it be the buildd admin's job to deal with it? Should not I get
> > notified of the error, and told to fix it?
> 
> I guess the notifying is what would become the buildd admin's job...

Why is this a manual job, rather than automated?

> If people want to not have to build and upload binary packages, they
> would better invest their time in setting up a central service that
> would build for them and would help in uploading succesful builds
> instead of complaining about thrown away binary packages IMHO.

I thought this was the purpose of the existing buildd network.

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1297621083.8023.4.ca...@havelock.lan

Re: Upcoming FTPMaster meeting

[Cyril Brulebois]

brian m. carlson  (13/02/2011):
> Also, FTBFS bugs are often filed by buildd admins; I'm sure they'd
> like to spend their time doing things other than filing those bugs.

Hell yes.

KiBi.


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[brian m. carlson]

On Sun, Feb 13, 2011 at 06:00:11PM +, Lars Wirzenius wrote:
> That's something I don't understand. If I upload a broken package, why
> should it be the buildd admin's job to deal with it? Should not I get
> notified of the error, and told to fix it?

I've seen packages that don't fail until the very end of the build.
This can waste a lot of buildd time, especially on very large packages.
So yes, as the maintainer, it may be your problem to fix, but failing to
test packages that as a result fail on the buildds won't make the buildd
admins very happy.

Also, FTBFS bugs are often filed by buildd admins; I'm sure they'd like
to spend their time doing things other than filing those bugs.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Sourceful uploads [Re: Upcoming FTPMaster meeting]

[Luk Claes]

On 02/13/2011 07:00 PM, Lars Wirzenius wrote:
> On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
>> I don;t think that is a good idea, there are way too many people not building
>> and testing their packages properly already, we don't want to give that work 
>> to
>> the buildd-admins...
> 
> That's something I don't understand. If I upload a broken package, why
> should it be the buildd admin's job to deal with it? Should not I get
> notified of the error, and told to fix it?

I guess the notifying is what would become the buildd admin's job...

If people want to not have to build and upload binary packages, they
would better invest their time in setting up a central service that
would build for them and would help in uploading succesful builds
instead of complaining about thrown away binary packages IMHO.

Cheers

Luk


-- 
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/4d581f5f.4080...@debian.org

Re: Upcoming FTPMaster meeting

[Lars Wirzenius]

On su, 2011-02-13 at 18:49 +0100, Bernd Zeimetz wrote:
> I don;t think that is a good idea, there are way too many people not building
> and testing their packages properly already, we don't want to give that work 
> to
> the buildd-admins...

That's something I don't understand. If I upload a broken package, why
should it be the buildd admin's job to deal with it? Should not I get
notified of the error, and told to fix it?

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1297620011.8023.2.ca...@havelock.lan

Re: MBF: switching away from homepage pseudo-header

[Stefano Zacchiroli]

On Sun, Feb 13, 2011 at 12:23:46PM +0100, Julien Cristau wrote:
> > PS lintian has a warning-level tag about that [2], which reports 250
> >packages vs 279 reported by my script. I'll check where the
> >differences come from before actually reporting the bugs.
> > 
> Isn't the lintian warning enough?  Or do we actually need the bugs for
> some reason?

My recalling of how we've handled this large scale transitions in the
past (hello /usr/doc) is that lintian usually goes a long way to reach a
critical mass of the migration, but that at some point you need to be a
bit more pushy than that.

There are various ways of being more pushy, one can be to raise the
lintian report level to error, but I believe in this case an explicit
bug report could be more useful (beside also enabling maintainers to
mark the change as pending in $VCS). Finally, some packages might have
been uploaded before the lintian warning was introduced and the
maintainers might have honestly missed the message. A bug report will
fix that.

I agree with Cyril that packages affected by this might be neglected,
but I don't want to entangle the two QA efforts. Maybe, if we go for the
MBF and tag the bugs properly, the presence of this bug can be perused
by monitors like bapase [1] as extra data to identify neglected
packages?

Cheers.

[1] http://udd.debian.org/bapase.cgi

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[Bernd Zeimetz]

On 02/10/2011 09:43 PM, Sandro Tosi wrote:
> On Thu, Feb 3, 2011 at 22:05, Joerg Jaspert  wrote:
>> * Throwaway DD built .debs (well, let's have the fight^Wdiscussion)
> 
> could you please keep in mind the bandwidth impaired and try something
> that avoids to upload those binary packages in the first place? but
> also something that avoids the risk of uploads without even trying to
> build the package first.

I don;t think that is a good idea, there are way too many people not building
and testing their packages properly already, we don't want to give that work to
the buildd-admins...

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


-- 
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/4d5819c2.3050...@bzed.de

Re: Upcoming FTPMaster meeting

[Stefano Zacchiroli]

On Sat, Feb 12, 2011 at 08:22:39PM +0100, Bernhard R. Link wrote:
> * Don Armstrong  [110211 23:01]:
> > 3) uniform, known build environments
> I think is a major disadvantage of this suggestion.

I'm unconvinced by your (implicit) argument that switching to an uniform
build environment will make the current testing of packages built in
"weird" environments any worse than the present situation.

Package maintainers are already expected to upload packages built in
clean environment. If they are not doing it, then we have a problem of
best practices which are followed by the developer community. Relying on
instances of that problem as test bench for weird build environments
doesn't look sane at all.

> Free Software is about being able to modify what you run. The day a
> user can no longer simply do a

Agreed.  But a (binary) distribution is about offering, first of all, an
uniform set of *binary* packages. If we have to balance our priorities
among (1) having that uniformity and (2) ensuring that packages build
properly in weird environment, then I would favor (1) over (2), no
doubt.

But actually no one is saying that we should have that trade-off. We can
work on (2) as well. Maybe you---as the only one who has up to now
voiced against this change---are interested in resurrecting some of the
past initiatives that tried to spot missing Build-Conflicts? If there is
energy to fight that battle, then going that way seems way more
promising than relying in random build environments prepared by
maintainers which are not using {cow,p}builder, when they should.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[Joey Hess]

Bernhard R. Link wrote:
> I'd rather say "doing it right" means to properly test it's build to be
> robust. Only ever testing in an artifical environment has a certain
> outcome: certain failure.

That depends. How closely does the artificial environment mirror the
avarage system as measured by popcon? How closely does the environment
in which I test build my package mirror the average system? It actually
seems likely that my environment is more diverged from the average
user's environment than is a buildd. I have a random set of build
dependencies installed. Nobody else on the planet is likely to have the
same set. I pick weird settings for alternatives, etc. We're all
weirdos. It seems strange to expect that checking that an arbitrary
package builds in a single arbitrary weird environment will be much
benefit to a more normal user, or even to another weirdo.

Whatever benefit there is has already been diluted a lot by the DDs
who always build their packages in clean environments already. Something
that has already become enough of a best practice that it's *embarrasing*
to say I don't. Probably that feeling means that more than 50% of you do
it, so we've already lost 50% of the benefit of ad-hoc building. That was
ok because we gained other, larger benefits.

So I don't think that we need grand schemes of test building every
package in purposefully weird systems. We could probably do as well as
we do now by instead stracing builds of some fraction, checking that
all files they try to accress come from build dependencies. dpkg-depcheck
can nearly do that now -- just modify it to report accesses to non-installed
files.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: MBF: switching away from homepage pseudo-header

[Andreas Tille]

On Sun, Feb 13, 2011 at 02:36:02PM +0100, Luca Capello wrote:
> >> That might also be a sign of packages lacking love, maybe some of them
> >> should be orphaned or dropped instead?

I used the "Missing homepage field in debian/control" on the Blends
tasks pages to enable some QA work which finally leaded to the effect
that we now have all packages in Debian Med that in fact have a valid
homepage (some packages do not have such thing any more)  and in *all*
cases the package needed some other polishing for some reasons.

So using the Homepage field as some means to spot packages which are
not maintained for some time seems to be a good idea and thus I would
welcome the MBF effort.  If it turns out that some bugs will be fixed
by just dropping the package in question that's a reasonable thing to
do as well.

> Please be aware that not all the packages need a recent upload,
> especially when you consider non-software packages (e.g. artworks,
> sounds and so on).  Even lintian does not produce any error when using
> old debhelper or policy versions (admitting the packages is fine with
> the new versions):

IMHO one upload per Debian release with a recent Standards-Version
should be done for every package.  It shows that the maintainer is
active and continues to be interested in the package.  Given that our
release cycle is > 1 year minimum this is a not too hard request.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
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/20110213165747.gc6...@an3as.eu

Re: Branching changelogs or not (Was: debian/changelogs, legacy work on packages and other distros)

[Philipp Kern]

On 2011-02-13, Andreas Tille  wrote:
> On Sat, Feb 12, 2011 at 09:47:22PM +0100, Julien Cristau wrote:
>> On Sun, Feb  6, 2011 at 16:51:26 +0100, Andreas Tille wrote:
>> >   3. Whether changelogs should be branched for different Debian
>> >  releases, be it testing-proposed-updates, backports or even
>> >  derivatives as Ubuntu or others.
>> As the package itself is branched, the changelog should be, too.
> While I regard this as a perfectly valid reason for your argument I
> regard the fact to have one single document which mentions any release
> of a package to keep the full history.  As far as I understood practice
> before is that we keep all changelog entries and the fact that the
> package is branched becomes IMHO obvious be the version number.

The version number in itself has no branching information.  debbugs gets some
branch information through the fact that people should upload with `-v' and the changelog snippets thus reaching the
.changes.

You can never manage to document all revisions due to the fact that a package
in stable won't be updated.  You should list all the revisions the current
upload is *based upon* in the changelog, which amounts to the branching bit
Julien said.

> I can not tell what argument is better but in any case we should iron
> out an advise in best packaging practice document to avoid some friction
> in the release process.

I never saw your style before, TBH.

Kind regards
Philipp Kern


-- 
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/slrnilg2om.2fs.tr...@kelgar.0x539.de

Re: Branching changelogs or not (Was: debian/changelogs, legacy work on packages and other distros)

[Andreas Tille]

On Sat, Feb 12, 2011 at 09:47:22PM +0100, Julien Cristau wrote:
> On Sun, Feb  6, 2011 at 16:51:26 +0100, Andreas Tille wrote:
> 
> >   3. Whether changelogs should be branched for different Debian
> >  releases, be it testing-proposed-updates, backports or even
> >  derivatives as Ubuntu or others.
> > 
> As the package itself is branched, the changelog should be, too.

While I regard this as a perfectly valid reason for your argument I
regard the fact to have one single document which mentions any release
of a package to keep the full history.  As far as I understood practice
before is that we keep all changelog entries and the fact that the
package is branched becomes IMHO obvious be the version number.

I can not tell what argument is better but in any case we should iron
out an advise in best packaging practice document to avoid some friction
in the release process.

Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
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/20110213164156.gb6...@an3as.eu

Re: Upcoming FTPMaster meeting

[Olaf van der Spek]

On Sun, Feb 13, 2011 at 12:58 PM, Roger Leigh  wrote:
> • adding build conflicts to ensure it will build on any arbitrary
>  system with a random selection of installed packages will always be
>  on a "best effort" basis:

Is this about automatically picking up optional dependencies (by
configure and friends)?

-- 
Olaf


--
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/aanlktimtq6vxbjvf-gm-qcglb2+av+sjdar_vpd97...@mail.gmail.com

Bug#613220: ITP: mon-contrib -- contributed tools, monitors and alert for mon package

[Dario Minnucci]

Package: wnpp
Severity: wishlist
Owner: Dario Minnucci 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: mon-contrib
  Version : 1.0
  Upstream Author : Various authors
* URL : https://sourceforge.net/projects/mon/files/mon-contrib
* License : Various
  Programming Lang: Various 
  Description : contributed tools, monitors and alert for mon package

 mon-contrib provides many user-contributed tools,
 monitors, and alerts for mon package.

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

iQIcBAEBCAAGBQJNV/Z0AAoJEKgvu4Pz1XAzcscQAKFx3/kLAv7J2wZI8Xy/c+xy
fb+B3SjR7QHwsXeH1jhAmry8bNGmgcIzFiz+/Q6TTaC5aDuktXparDMw1sLrhPza
cleLtmSILotk0abZnJw3nKq/xbAwHLSIMF6BpjkCaDenkSDvqojFq7PwHjd+TNbJ
/hCKa0vX8V1qKMp58cL4WbjuxasQ5DDHTo/QO9v1NwKAWADCzldduKbQKACG2lBh
DkxXDEpEjzc53m/PzQhI5/gAqtH2OOBIuAACaePhaR9yLj9gCTtasjyaZ27EWm5D
mWePV0TwB8Ctn69ziGeRjpNgIjUt3OxvoozfO7O7U3bCy4VhUTU88IdtZFRkmQnQ
dYNUtR2b7BwKLuqf9YMbkQKGoBDteO7jEk/tuVlTNcTvX9Ps+WKqfGt2MKnqI9Jk
WKSUJ2lyQI9+R7OW1MpfuCnH3jrCOf7fKMpJWqPPNU878DzpKNcSjFgmyc37oPyz
pzgm9h6S/yNoMeP/AlSLciCoi8OrgFE5udVsYrTyD4YGl5942uNCrQz4v55HnBay
79ACG92ibht8Cp1l28ouRdlC/0ZtogngocEuNg12pvUicnNG+9/fNQW3pl47fG0J
Rw+zk78YZAcS06VTARHigRY3s2JuQVr8qG1P6pDdy5L7t4J1weFyagrC214R/yWy
reIWENpkzCIOizraKAPn
=xzHI
-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/20110213151921.23860.60537.report...@dharma.midworld-networks.com

Bug#613217: ITP: python-logging-extra -- Generic utilities for the Python logging facility

[David Villa Alises]

Package: wnpp
Severity: wishlist
Owner: David Villa Alises 


  Package name: python-logging-extra
  Version : 0.1
  Upstream Author : David Villa Alises 
  URL : 
http://arco.esi.uclm.es/var/svn/public/prj/python-logging-extra
  License : GPL
  Programming Lang: Python
  Description : Generic utilities for the Python logging facility

 That includes logging handlers for authenticated SMTP (with TSL),
 Jabber XMPP and desktop notifications (through libnotify). It has
 also some additional formaters: ColorFormatter, etc.
  



-- 
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/20110213151226.19456.91533.reportbug@localhost.localdomain

Bug#613213: RFP: libmoosex-types-netaddr-ip -- NetAddr::IP related types and coercions library for Moose

[intrigeri+debian]

Package: wnpp
Severity: wishlist

* Package name: libmoosex-types-netaddr-ip
  Version : 0.04
  Upstream Author : Todd Caine 
* URL or Web page : http://search.cpan.org/~tcaine/MooseX-Types-NetAddr-IP-0.04/
* License : Same as Perl 5.10.1 or, at your option, any later version 
of Perl 5 you may have available.
  Description : NetAddr::IP related types and coercions library for Moose

No open bug in RT, code is sane, almost perfect CPAN Testers reports.
Every dependency is in Debian already.

Bye,
-- 
  intrigeri 



-- 
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/85vd0onfsl@boum.org

Bug#613211: RFP: libmoosex-types-portnumber -- IANA port number type library for Moose

[intrigeri+debian]

Package: wnpp
Severity: wishlist

* Package name: libmoosex-types-portnumber
  Version : 0.02
  Upstream Author : Thiago Rondon 
* URL or Web page : http://search.cpan.org/~tbr/MooseX-Types-PortNumber-0.02/
* License : Artistic or GPL-1+
  Description : IANA port number type library for Moose

Almost perfect CPAN Testers reports, no open bug in RT, code is sane.
Copyright and license information seems clear enough to me in the source.

Bye,
-- 
  intrigeri 



-- 
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/851v3couju@boum.org

Bug#613210: ITP: replicatorg -- Simple 3D printing program

[Nicolas Dandrimont]

Package: wnpp
Severity: wishlist
Owner: Nicolas Dandrimont 


* Package name: replicatorg
  Version : 0023
  Upstream Author : Zach Hoeken, Marius Kintel, Adam Mayer et al.
* URL : http://replicat.org/
* License : GPLv2
  Programming Lang: Java (UI), Python (CAD file conversion backends)
  Description : Simple 3D printing program

 ReplicatorG is a simple, open-source 3D printing program.
 .
 It is designed to drive a Makerbot CupCake CNC, a RepRap machine, or
 any generic CNC machine that is able to understand G-code.
 .
 This software is able to directly drive the machine with a G-code
 file, or can process an STL file to generate the G-Code. An
 integrated interface allows the user to do simple transformations on
 the STL object before processing it.



-- 
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/20110213145028.16344.53288.report...@poincare.crans.org

Bug#613209: O: jabberd14 -- Instant messaging server using the Jabber/XMPP protocol

[Miguel Landaeta]

Package: wnpp
Severity: normal

I intend to orphan the jabberd14 package. I no longer use
it and active upstream development has practically stopped.
The last upstream release was on July 2007.

My use-case for this package was very simple, just a very
simple jabber server in a domestic LAN, without SSL and
without server to server communication.
For a very simple jabber server I would recommend to use
prosody. For other needs, ejabberd would do just fine.

I remark that because this package is bitrotting and almost
all outstanding bugs have to do with those features that I
don't use and I'm not really interested.

In fact I'm wondering if I should ask its removal from the
archive. If nobody adopt it soon I'll ask for removal.

Cheers,

-- 
Miguel Landaeta, miguel at miguel.cc
secure email with PGP 0x7D8967E9 available at http://keyserver.pgp.com/
"Faith means not wanting to know what is true." -- Nietzsche



-- 
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/20110213144450.ga2...@miguel.cc

Re: Upcoming FTPMaster meeting

[Michael Banck]

On Sun, Feb 13, 2011 at 03:23:30PM +0100, Bernhard R. Link wrote:
> * Holger Levsen  [110213 13:13]:
> > On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> > > But it is an essential part of doing it right, so we should try to do
> > > our best and not just give up early.
> >
> > doing it right certainly doesnt mean to create a stable distro build in an
> > unpredicatable environment.
> 
> I'd rather say "doing it right" means to properly test it's build to be
> robust. Only ever testing in an artifical environment has a certain
> outcome: certain failure.

It's not an artificial environment, it's a controlled environment.  You
keep repeating that you think this is a problem, but the general
consensus seems to be that we should either switch to source-only
uploads, or at least rebuild uploaded binary .debs.


Michael


-- 
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/20110213145123.ga4...@nighthawk.chemicalconnection.dyndns.org

Re: Upcoming FTPMaster meeting

[Holger Levsen]

Hi,

On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> I'd rather say "doing it right" means to properly test it's build to be
> robust. Only ever testing in an artifical environment has a certain
> outcome: certain failure.

Nobody said people should stop rebuilding packages on those 100 derivatives we 
already have or stop creating random backports in random environments (or or 
or). And nobody said we shouldn't do other systematic rebuilds in known 
broken environments. So, this kind of testing will not stop.

It's still completly beyond me, why you think it's useful to randomly build 
1/12 of our binary packages in a random environment, ship that as stable to 
the world and not even make clear which those packages are, plus throwing 
away the build information too. It's a mess, and a harmful one. As you 
observed, it might have side benefits sometimes, but those can be achieved by 
other means, which don't have the downsides discussed here.

EOT for me.


cheers,
Holger


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

Re: Upcoming FTPMaster meeting

[Charles Plessy]

Le Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link a écrit :
> Porters trying to fix your crappy non-portable software

> Allowing things to build in a non-artificial environment is simply an
> important part of being a good free software citizen.

> we should try to do our best and not just give up early.

I am very disoriented by your disagreement as I have the impression that nobody
proposed that failures to build on non-minimal environments should be taken
less seriously as they are now.

More and more developers use a chroot for the package they upload. This does
not mean that they do not try to build it on non-artificial environments before
that final step.

What we probably miss is the local build logs from the package preparation.
More and more packages are stored in a VCS. Recently, I have started to store
build logs in a branch of the packages I maintain with Git. Is there an interest
for standarisation ?

In the context of this discussion, the advantage of having the local build logs
stored somewhere is that we would be able to know how many developers upload
packages built in a chroot.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20110213143021.ge2...@merveille.plessy.net

Re: Upcoming FTPMaster meeting

[Bernhard R. Link]

* Holger Levsen  [110213 13:13]:
> On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> > But it is an essential part of doing it right, so we should try to do
> > our best and not just give up early.
>
> doing it right certainly doesnt mean to create a stable distro build in an
> unpredicatable environment.

I'd rather say "doing it right" means to properly test it's build to be
robust. Only ever testing in an artifical environment has a certain
outcome: certain failure.

Bernhard R. Link


-- 
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/20110213142330.ga13...@pcpool00.mathematik.uni-freiburg.de

Re: Upcoming FTPMaster meeting

[Adam Borowski]

On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
> * Roger Leigh  [110212 21:58]:
> > The other side to this is that fixing such bugs gains us very litle.
> >
> > If we have a guaranteed clean build environment + package build deps,
> > we have as complete consistency as is practicable.
> 
> Allowing things to build in a non-artificial environment is simply an
> important part of being a good free software citizen. We as packagers do
> not like it if upstream has an arcane build system that mostly only
> works on their build servers, so we should also allow out users to
> get things builds.

This raises a question about how strict build-conflicts we want.

For example, any package built on a system with nvidia's drivers will be
built against them rather than mesa due to diversions, and will be unusable
anywhere else.

Thus, it is tempting to slap build-conflicts in to ensure you won't
accidentally upload such packages.  On the other hand, it means you and
anyone else who wants to hack on this code has to use a chroot for builds
-- not really acceptable.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
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/20110213141017.ga...@angband.pl

Re: RFA: all my packages

[Christoph Egger]

Hi!

Decklin Foster  writes:
> I'm looking for a new maintainer for, well, any of these. My heart is
> not in it anymore and most of them have been neglected for a while.
> Recently my free time has been taken up by other things (mainly my job)
> and I forsee that continuing.
>
> http://qa.debian.org/developer.php?login=decklin%40red-bean.com

I see Mnemosyne on that list. As I'm using this package I'd take it
over. However I noticed your upstream there too. How do you plan to
continue there?

Regards

 Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?


pgpkyyXjEmPHT.pgp
Description: PGP signature

Re: MBF: switching away from homepage pseudo-header

[Luca Capello]

Hi there!

On Sun, 13 Feb 2011 12:31:54 +0100, Francesco P. Lovergine wrote:
> On Sun, Feb 13, 2011 at 12:27:34PM +0100, Cyril Brulebois wrote:
>> Stefano Zacchiroli  (13/02/2011):
>> > I hereby propose a mass bug filing, severity minor, requesting
>> > migration to the proper debian/control field.
>> 
>> That might also be a sign of packages lacking love, maybe some of them
>> should be orphaned or dropped instead?
>> 
>
> +1 
>
> Very outdated debhelper versions, policy versions and very aged last upload 
> dates
> could be signs of MIA developers and abandonware.

Please be aware that not all the packages need a recent upload,
especially when you consider non-software packages (e.g. artworks,
sounds and so on).  Even lintian does not produce any error when using
old debhelper or policy versions (admitting the packages is fine with
the new versions):

  
  


Thx, bye,
Gismo / Luca


pgpPuUauIUUsx.pgp
Description: PGP signature

Re: Upcoming FTPMaster meeting

[Holger Levsen]

Hi,

On Sonntag, 13. Februar 2011, Bernhard R. Link wrote:
> But it is an essential part of doing it right, so we should try to do
> our best and not just give up early.

doing it right certainly doesnt mean to create a stable distro build in an 
unpredicatable environment.

its rather done using a predictable good (and also predicatable bad) 
environment(s).


cheers,
Holger


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

Re: Upcoming FTPMaster meeting

[Bernhard R. Link]

* Lars Wirzenius  [110212 20:40]:
> On la, 2011-02-12 at 20:22 +0100, Bernhard R. Link wrote:
> > If the packages used are only ever built in unnatural virgin
> > environments, there is basically no testing if building them on
> > a real user machine works. And things not tested usually just stop
> > working after some time...
>
> Right now, such testing of such build environments is pretty haphazard
> already. Developers presumably build things with debuild on their
> development machines, but that's a very small test.

Testing is not good, and I think it got a lot worse in recent years.
New developers are nowadays told to only build packages in artificial
environments, buildds test this less and less (in the past, they mostly
only installed new packages and only deinstalled for conflicts, now the
mayority or even all deinstall as much as they can).

> If we wanted to be serious about this, it would be nice for someone to
> set up a maximal build chroot: something with as many packages installed
> as possible.

That is a nice test, but also another additional test. Apart from
problems with automatically installing packages (many packages not
usually being build-depended on tend to want to start things or get
stuff configured or things like that), you can never test all possible
combinations. While DD unstable machines usually sould have the
common combinations of packages installed, that a user may also have.

> On the other hand, I don't see that this is all that important. Most
> packages will build fine in a dirty environment, and if there's trouble,
> users can report problems, and then they can get fixed.

Users or porters or non-maintainer DDs usually do not look at packages
without a reason, but because of other problems. Making them run into
unrelated problems they might even need some time to properly recognize
as the cause for their problems is the worst time this problem can show
up.

Bernhard R. Link


-- 
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/20110213120041.gb11...@pcpool00.mathematik.uni-freiburg.de

Re: Upcoming FTPMaster meeting

[Roger Leigh]

On Sun, Feb 13, 2011 at 12:42:57PM +0100, Bernhard R. Link wrote:
> * Roger Leigh  [110212 21:58]:
> Allowing things to build in a non-artificial environment is simply an
> important part of being a good free software citizen. We as packagers do
> not like it if upstream has an arcane build system that mostly only
> works on their build servers, so we should also allow out users to
> get things builds.
> 
> > The former situation is simple, robust and maintainable.  But the
> > latter, it's a virtually intractable problem, and given the lack of
> > concern about it up to now, it's not a major worry for most people,
> > and from a cost/benefit POV it doesn't look practical.
> 
> Nobody claims it is easy.
> 
> I think there is even a measurable part of people producing binary-only
> "freeware" mostly because they do not want to be bothered by people with
> problems compiling their source.
> 
> But it is an essential part of doing it right, so we should try to do
> our best and not just give up early.

I am by no means saying we shouldn't do it.  I'm just saying that:

• having the buildds using a clean minimal environment is good for
  the consistency of officially built and distributed packages.
  In this situation, we specify *exactly* what is required, and
  this is possible to get exactly right.

• adding build conflicts to ensure it will build on any arbitrary
  system with a random selection of installed packages will always be
  on a "best effort" basis:
  · there are too many combinations to test
  · as the source packages and the rest of the system changes, the
conflicts that are added may become outdated, and without
proper testing will bitrot
  · as the system changes, new conflicts may be required
  · we can not guarantee that the package will be identical to those
built in a clean+minimal environment; there are just too many
variables, especially when features are autodetected

I would have thought that the current situation, where developers add
conflicts as they find such things on their own systems, or others
report them as they find them, is quite sufficient.  But supporting
much more than this is not practical.  I am not suggesting at all that
packages which don't build on more than minimal setups are not broken,
just that we can't guarantee a successful and/or reproducible build on
every random system out there.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[Bernhard R. Link]

* Roger Leigh  [110212 21:58]:
> The other side to this is that fixing such bugs gains us very litle.
>
> If we have a guaranteed clean build environment + package build deps,
> we have as complete consistency as is practicable.

You might have no problem producing nice binary packages so people might
consume those binary packages. Users not only wanting to consume binary
packages but to extend their software, to fix bugs that bother them
(i.e. helping you) will have a problem. Porters trying to fix your
crappy non-portable software will have to jump through hoops (i.e. be
less willing to help you fix bugs that might eventually also pester the
more maintain architectures). And so on.

Allowing things to build in a non-artificial environment is simply an
important part of being a good free software citizen. We as packagers do
not like it if upstream has an arcane build system that mostly only
works on their build servers, so we should also allow out users to
get things builds.

> The former situation is simple, robust and maintainable.  But the
> latter, it's a virtually intractable problem, and given the lack of
> concern about it up to now, it's not a major worry for most people,
> and from a cost/benefit POV it doesn't look practical.

Nobody claims it is easy.

I think there is even a measurable part of people producing binary-only
"freeware" mostly because they do not want to be bothered by people with
problems compiling their source.

But it is an essential part of doing it right, so we should try to do
our best and not just give up early.

Bernhard R. Link


-- 
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/20110213114257.ga11...@pcpool00.mathematik.uni-freiburg.de

Re: MBF: switching away from homepage pseudo-header

[Francesco P. Lovergine]

On Sun, Feb 13, 2011 at 12:27:34PM +0100, Cyril Brulebois wrote:
> Stefano Zacchiroli  (13/02/2011):
> > I hereby propose a mass bug filing, severity minor, requesting
> > migration to the proper debian/control field.
> 
> That might also be a sign of packages lacking love, maybe some of them
> should be orphaned or dropped instead?
> 

+1 

Very outdated debhelper versions, policy versions and very aged last upload 
dates
could be signs of MIA developers and abandonware.

-- 
Francesco P. Lovergine


-- 
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/20110213113154.ga2...@frankie.is-a-geek.org

Re: MBF: switching away from homepage pseudo-header

[Cyril Brulebois]

Stefano Zacchiroli  (13/02/2011):
> I hereby propose a mass bug filing, severity minor, requesting
> migration to the proper debian/control field.

That might also be a sign of packages lacking love, maybe some of them
should be orphaned or dropped instead?

KiBi.


signature.asc
Description: Digital signature

Re: MBF: switching away from homepage pseudo-header

[Julien Cristau]

On Sun, Feb 13, 2011 at 12:12:51 +0100, Stefano Zacchiroli wrote:

> PS lintian has a warning-level tag about that [2], which reports 250
>packages vs 279 reported by my script. I'll check where the
>differences come from before actually reporting the bugs.
> 
Isn't the lintian warning enough?  Or do we actually need the bugs for
some reason?

Cheers,
Julien


signature.asc
Description: Digital signature

MBF: switching away from homepage pseudo-header

[Stefano Zacchiroli]

Upgrading my own server to Squeeze, I've stumbled upon some stats that
I've been maintaining for quite a while. One of them is about how Debian
packages declare upstream homepage, by using either the old "Homepage"
pseudo-header in package description or the new field as per policy
§5.6.23, or both(!).  Live data about that are available at [1].

The advantage of the new format is that it is uniformly handled by
various services, such as the PTS and packages.d.o, and can be more
uniformly extracted from package information.

I hereby propose a mass bug filing, severity minor, requesting migration
to the proper debian/control field.  A dd-list is attached. Please let
me know if you spot false positives.

Cheers.


PS lintian has a warning-level tag about that [2], which reports 250
   packages vs 279 reported by my script. I'll check where the
   differences come from before actually reporting the bugs.

[1] http://upsilon.cc/~zack/stuff/homepage-field/
[2] http://lintian.debian.org/tags/description-contains-homepage.html

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams
Gregory Colpart (evolix) 
   php-date
   php-file

Felipe Augusto van de Wiel (faw) 
   iselect

Adam Cécile (Le_Vert) 
   cobalt-panel-utils
   pythondialog
   stymulator
   yum-metadata-parser (1.1.2-1)

Jari Aalto 
   dlume

David Villa Alises 
   ows

Bill Allombert 
   gap-ctbllib
   gap-gdat

Nacho Barrientos Arias 
   libconvert-ber-perl

Nacho Barrientos Arias 
   pysesame

Chris AtLee 
   rofs-fuse

Richard Atterer 
   hama-slide-mouse-control

Sebastien Bacher 
   gdeskcal
   gtkterm (0.99.5-1)
   rubrica

Alan Baghumian 
   aspell-hy

Edelhard Becker 
   cvstrac

Chris Vanden Berghe 
   meanwhile

Fathi Boudra 
   log4cpp-doc

Nicholas Breen 
   jigl

Paul Brossier 
   aconnectgui
   alsamixergui

Ross Burton 
   libgconf-bridge

Paul Cager 
   id3tool
   micro-proxy

Martin Braure de Calignon 
   gaim-themes

Devin Carraway 
   libclamav-client-perl

Francesco Cecconi 
   libemail-find-perl
   libhtml-fromtext-perl

Cyril Chaboisseau 
   qgo

Arnaud Cornet 
   libbluecloth-ruby

Kevin Coyner 
   bbmail
   bbrun
   bbtime
   imediff2
   kodos
   mailcheck
   mrename
   rpl

Tibor Csögör 
   wpp

Jure Cuhalev 
   aspell-sl

Paul Cupis 
   doctorj

Luke Cycon 
   keytouch

Rafael D'Leon 
   balance

Debian Arabic Packaging Team 
   aspell-ar
   aspell-ar-large
   aspell-fa

Debian GIS Project 
   gpx2shp

Debian Java Maintainers 
   libjazzy-java
   libswidgets-java
   libtoolbar-java

Debian KDE Extras Team 
   keep (0.4.0-1)

Debian Perl Group 
   libdata-walk-perl
   libemail-send-io-perl
   libtie-ical-perl

Debian Python Modules Team 
   pyip

Debian Science Team 
   suitesparse-metis

Debian VoIP Team 
   stun

Debian/Ubuntu Zope Team 
   python-mechanize

Kenny Duffus 
   dcfldd

Michel Dänzer 
   driconf

Zak B. Elep 
   ecb
   gnome-ppp
   libmemcache

Raphael Enrici 
   yersinia

Baruch Even 
   ketchup
   mdk

Khalid El Fathi 
   gpass

Alexandre Fayolle 
   pyqonsole (0.2.0-2.3)
   python-unit

Bartosz Fenski 
   csmash-demosong
   netw-ib-ox-ag
   pystatgrab (0.4-1.1)

Charles Fry 
   courierpassd
   courieruserinfo
   php-simpletest
   wmfire

Hans Fugal 
   nyquist

Alexander GQ Gerasiov 
   mdf2iso

Martin A. Godisch 
   cgoban
   wmpuzzle

Thomas Goirand 
   php-auth-http
   php-config
   php-image-barcode

Diego Andrés Asenjo González 
   asterisk-prompt-es-co

Jack Grahams 
   png2html

Mod_removeip Packaging Group 
   libapache-mod-removeip

Debian QA Group 
   libqwt
   multisync
   multisync (0.82-9)
   texmacs-extra-fonts
   wavesurfer

Guido Guenther 
   wmwave (0.4-9)

Aurélien GÉRÔME 
   cpuid
   hfsutils
   hybserv

Henrique Haas 
   trueprint

Yaroslav Halchenko 
   jsmath-fonts
   jsmath-fonts-sprite

Rasmus Bøg Hansen 
   sigit

gregor herrmann 
   fullquottel

Mark Hindley 
   pfm

Horde Maintainers 
   chora2

ZhengPeng Hou 
   diveintopython-zh

Chris Howie 
   yics

Ben Hutchings 
   maypole
   maypole-authentication-usersessioncookie
   maypole-plugin-upload

Mario Iseli 
   cobex
   yudit

Mario Iseli 
   aee
   libezv24

Michael Janssen 
   bittorrent

Aurelien Jarno 
   keybled

Mark Johnson 
   docbook-html-forms
   docbook-jrefentry
   docbook-mathml
   docbook-slides
   docbook-slides-demo
   docbook-website
   w3-dtd-mathml

Isaac Jones 
   hugs98

Thanasis Kinias 
   sanduhr

Tatsuya Kinoshita 
   chalow
   x-face-el

Ivan Kohler 
   libbusiness-onlinepayment-viaklix-perl

Rafael Laboissiere 
   gpcl

Asheesh Laroia 
   ccd2iso

Julien Lavergne 
   gnome-launch-box (0.2-1.1)

Ana Beatriz Guerrero Lopez 
   empy

Pierre Machard 
   greed

Bart Martens 
   grdesktop

Claudio Matsuoka 
   coldfire

Mika Matsuzaki 
   bfm

Jose Carlos Medeiros 
   kni

Re: patch removal of --unified-reject-files breaks quilt

[Marco d'Itri]

On Feb 13, "Steve M. Robbins"  wrote:

> Patch 2.6.1 has removed this "lenny compatibility option" deliberately.
> How can we get quilt working again?
vi ~/.quiltrc

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Upcoming FTPMaster meeting

[Lars Wirzenius]

On su, 2011-02-13 at 08:41 +0100, Lucas Nussbaum wrote:
> On 12/02/11 at 15:29 -0600, Raphael Geissert wrote:
> > Lars Wirzenius wrote:
> > > 
> > > If we wanted to be serious about this, it would be nice for someone to
> > > set up a maximal build chroot: something with as many packages installed
> > > as possible. Then do test builds of all packages, and report problems.
> > > (Then upgrade the chroot, install as many new packages as possible, and
> > > rebuild everything. Repeat forever.)
> > 
> > http://lists.debian.org/debian-devel/2008/01/msg00869.html
> 
> As Raphael pointed out, I did some work on this in the past. But I
> consider it mostly a waste of time, since the benefits are very little.
> 
> Also, there are many areas where automated testing is interesting /
> useful, but where we don't do everything we could yet, like the use of
> test suites, or installation/upgrades testing in setups that are more
> complex than piuparts'. I would rather see someone work on this.

In case it was unclear: I fully agree!

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
http://www.branchable.com/


-- 
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/1297585814.3105.105.ca...@havelock.lan

Re: there is /usr/lib64 symlink but no /usr/local/lib64

[Tollef Fog Heen]

]] Steve Langasek 

| That seems to require /usr/local/lib64 even if we *don't* include
| /usr/lib64, right?  Should we amend policy to take this exception to the
| FHS?  Please open a bug report on policy if you think we should.

I've just opened such a bug.

| /me goes back to making lib64 obsolete ;)

Yay! :-)

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
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/87lj1ktkpm@qurzaw.varnish-software.com