(Other) mailing list seems to fail in delivering messages

2011-03-30 Thread Andreas Tille 
Hi,

since some days I noticed that no mails which I have sent to
debian-...@lists.debian.org hit my mail mailbox and the footer
of the mailing list archive says:

   The last update was on 21:20 GMT Sat Mar 26. There are 216 messages. Page 1 
of 1.

So this is a heads up for listmaster and a simple test whether
debian-devel list might work correctly.  Any similar observations of
other people reading other lists?

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/20110330072544.gd28...@an3as.eu

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Goswin von Brederlow 
Andreas Metzler  writes:

> In gmane.linux.debian.devel.general Joey Hess  wrote:
>> Steve McIntyre wrote:
>>> There are uses I've heard about, including (apparently quite common)
>>> using CDs and DVDs to seed a mirror on a Windows server.
>
>> If I had to chose between that working, and not needing to worry about
>> filename lengths, I'd choose the latter.
>
>>> >Is it possible to provide Joliet filenames for only a subset of files?
>
>>> It is, yes. But not something I'd like to do if we can avoid it.
>
>> One approach then would be to omit joliet filenames for the few long
>> packages. This would not even impact your use case above much, since
>> any mirror seeded from files from CDs needs a further sync step.
>
> Hello,
> An alternative approach would be to use a different *filename* while
> keeping the package name unchanged (This could be done on both mirrors
> and CD.) Iirc apt/dpkg have absolutely no problem with "foo.deb"
> containing version 1:3.2.1-11+squeeze2 of the 
> openoffice.org-report-builder-bin i386 package. I do not know about
> dak, though.
>
> cu andreas

Doesn't work for sources as the dsc files are signed and therefore
unalterable. Unless you want to teach dpkg about the renaming rules too.

MfG
Goswin


-- 
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/87y63xxbl1.fsf@frosties.localnet

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Goswin von Brederlow 
Joerg Jaspert  writes:

>   Additionally we will support new architectures like armhf, sparc64,
>   powerpc64, sh4 and s390x in case someone does the neccessary
>   groundwork needed prior to an inclusion, and gets all the needed
>   preconditions settled.  If porters want to discuss inclusion, they
>   should contact us.

Hi,

did you discuss supporting partial architecture for use with multiarch?

What I mean here is that for example powerpc64 doesn't need a full set
of packages. There is no need to run bash in 64bit for example. But some
people might need a 64bit postgreql. So it would be enough to build only
a subset of packages for powerpc64 and run the buildds under multiarch
with powerpc + powerpc64 configured.

Obviously that still is work in progress but with dpkg and apt finally
getting multiarch ready and the emdebian people working on cross
compilers and cross building this shouldn't be too far in the future
now.

The question is: Would you support a partial port that is just an
extention of an existing port or does it need to be a full port?

MfG
Goswin


-- 
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/87tyelxa7q.fsf@frosties.localnet

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Bastian Blank 
On Tue, Mar 29, 2011 at 10:50:31AM -0300, Henrique de Moraes Holschuh wrote:
> At that point, exactly why should you not upload the entire thing?

In most parts of the world you actually have to pay for data transfer.
So why transfer something that is not going to be used at all?

Bastian

-- 
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9


-- 
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/20110330095421.ga7...@wavehammer.waldi.eu.org

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Bastian Blank 
On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote:
> I talked with Joerg at the meeting and we agreed that arch-based admin
> keyrings aren't needed.  If you feel so strongly about it, I think you
> should take it up yourself and make [0] support one keyring per arch.

Why do you want one keyring per arch? What problem are you trying to
solve with this?

Bastian

-- 
Landru! Guide us!
-- A Beta 3-oid, "The Return of the Archons", stardate 3157.4


-- 
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/20110330095539.gb7...@wavehammer.waldi.eu.org

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Adam Borowski 
On Wed, Mar 30, 2011 at 11:54:21AM +0200, Bastian Blank wrote:
> On Tue, Mar 29, 2011 at 10:50:31AM -0300, Henrique de Moraes Holschuh wrote:
> > At that point, exactly why should you not upload the entire thing?
> 
> In most parts of the world you actually have to pay for data transfer.
> So why transfer something that is not going to be used at all?

What if the .debs were mangled at dupload/dput time?
All that matters is the list of files, their lengths and possibly hashes.

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


signature.asc
Description: Digital signature

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Philipp Kern 
On Wed, Mar 30, 2011 at 11:55:39AM +0200, Bastian Blank wrote:
> On Mon, Mar 28, 2011 at 10:19:32PM +, Philipp Kern wrote:
> > I talked with Joerg at the meeting and we agreed that arch-based admin
> > keyrings aren't needed.  If you feel so strongly about it, I think you
> > should take it up yourself and make [0] support one keyring per arch.
> Why do you want one keyring per arch? What problem are you trying to
> solve with this?

I think it's called principle of least privilege.  Of course we could also let
all buildd admins add arbitrary keys for any architecture and hope that it
isn't abused, given that you're able to upload from anywhere in the world
using the key.

(But then everyone who adds keys for his machines at home will just get his
privileges revoked anyway.  Question is if harm is done at that point already.)

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

Re: Meeting Minutes, FTPMaster meeting March 2011

2011-03-30 Thread Bastian Blank 
On Wed, Mar 30, 2011 at 12:16:00PM +0200, Philipp Kern wrote:
> On Wed, Mar 30, 2011 at 11:55:39AM +0200, Bastian Blank wrote:
> > Why do you want one keyring per arch? What problem are you trying to
> > solve with this?
> I think it's called principle of least privilege.  Of course we could also let
> all buildd admins add arbitrary keys for any architecture and hope that it
> isn't abused, given that you're able to upload from anywhere in the world
> using the key.

They still can use their personal keys to do the uploads, so I don't
really see the difference.

> (But then everyone who adds keys for his machines at home will just get his
> privileges revoked anyway.  Question is if harm is done at that point 
> already.)

And it would be acceptable if a person in the wbadm group would do the
same?

This keyring adds new keys with a subset of permissions of the personal
key of the requestor. It still can be traced properly to the "owner". So
what harm should be done?[1]

Bastian

[1] Personally I have signing subkeys. This is a similar concept.
-- 
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, "I, Mudd", stardate 4513.3


-- 
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/20110330110032.gc7...@wavehammer.waldi.eu.org

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Steve McIntyre 
On Sat, Mar 26, 2011 at 08:56:14AM +0100, Raphael Hertzog wrote:
>On Fri, 25 Mar 2011, Steve McIntyre wrote:
>> On Fri, Mar 25, 2011 at 12:28:54PM -0400, Joey Hess wrote:
>> >Steve McIntyre wrote:
>> >> There are uses I've heard about, including (apparently quite common)
>> >> using CDs and DVDs to seed a mirror on a Windows server.
>> >
>> >If I had to chose between that working, and not needing to worry about
>> >filename lengths, I'd choose the latter.
>> 
>> We already have arbitrary limits on filename length (~200 bytes or so
>> on RockRidge), even before this. I'm just proposing to lower them for
>> a common use case. Do we really care about supporting *very* long
>> names here?
>
>I think so. The package with long names tend to follow a naming policy
>that sort of imposes the long name... so if we put a too-short limit
>then we're asking them to make an exception in the naming policy.

So what's a reasonable name length limit then? 80? 150? 2000?

>> >One approach then would be to omit joliet filenames for the few long
>> >packages. This would not even impact your use case above much, since
>> >any mirror seeded from files from CDs needs a further sync step.
>> 
>> I'd be much happier to not have to special case yet another thing in
>> the CD scripts. That way potentially leads to unforeseen bugs in the
>> future, for very little gain.
>
>What happens if you try to put too-long filenames on the CD with Joliet
>enabled?
>
>Does it fail to build? Are there options to rename the files
>automatically?

It will fail to build. I don't want to rename the files, I'd like to
get some agreement on how to fix the problem properly.

>If it means we have some unexpected filenames for long filenames on
>Windows, it's not a big deal IMO. 

For people who may want to verify the files on their CDs it might be.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Is there anybody out there?


-- 
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/20110330105139.gg7...@einval.com

Support for SMACK security framework

2011-03-30 Thread Joachim Wiedorn 
Hello,

since kernel 2.6.25 SMACK is inside the official kernel as alternative to
the large SELinux framework. But until now there are no userspace tools
packaged in Debian to administrate SMACK. And also there are no additional
patches made for system tools (coreutils, ssh, busybox ...).

How is the opinion about support for this alternative security framework?

Were this theme discussed in the past for Debian?

Does some Debian developer want to add userspace support into Debian?

Does anybody know reason against support of SMACK?


By the way: 
The main (upstream) developer Casey Schaufler  
has switched his work to MeeGo (http://www.meego.com) where some packages
for SMACK are in current development.

---
Have a nice day.

Joachim (Germany)


-- 
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/20110330131427.11d1c...@jupiter.home

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Steve McIntyre 
On Sat, Mar 26, 2011 at 03:18:12PM +0100, gregor herrmann wrote:
>On Sat, 26 Mar 2011 08:56:14 +0100, Raphael Hertzog wrote:
>
>> > We already have arbitrary limits on filename length (~200 bytes or so
>> > on RockRidge), even before this. I'm just proposing to lower them for
>> > a common use case. Do we really care about supporting *very* long
>> > names here?
>> I think so. The package with long names tend to follow a naming policy
>> that sort of imposes the long name... so if we put a too-short limit
>> then we're asking them to make an exception in the naming policy.
>
>Right, that's certainly true for the lib.*-perl packages, and I
>wouldn't know how we should rename them in a sane way.

In the worst case that I'm looking at, I'm a little surprised by the
names here on two fronts:

libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz

1. Why the "bundle" ?

2. Why such a silly long name? What will happen if somebody comes
   along with another perl module to add to this bundle, but with a
   name twice as long? Does the source name for this tarball have to
   contain the whole of the bundle name?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Welcome my son, welcome to the machine.


-- 
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/20110330105622.gh7...@einval.com

Re: Support for SMACK security framework

2011-03-30 Thread Russell Coker 
On Wed, 30 Mar 2011, Joachim Wiedorn  wrote:
> How is the opinion about support for this alternative security framework?

I think it would be good to have it.

> Were this theme discussed in the past for Debian?

Not AFAIK.

> Does some Debian developer want to add userspace support into Debian?

Why don't you do it?

> Does anybody know reason against support of SMACK?

No-one has been interested in doing the coding.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/


-- 
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/201103302245.53366.russ...@coker.com.au

Re: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread Henrique de Moraes Holschuh 
On Wed, 30 Mar 2011, Steve McIntyre wrote:
> >I think so. The package with long names tend to follow a naming policy
> >that sort of imposes the long name... so if we put a too-short limit
> >then we're asking them to make an exception in the naming policy.
> 
> So what's a reasonable name length limit then? 80? 150? 2000?

Do you want it to actually work worth a damn (i.e. not croak on ext2-4, xfs
and btrfs at the very least)?

Don't let it go over 250 *bytes* (not characters. UTF-8 and all that...).

We really need to curb the long name insanity in the head.  And might as
well do it in a way that does not hinder our hability to get data where it
is needed, i.e. keep it under 100 chars.

There really is no excuse for such long deb names.  If a naming convention
"requires" it, fix the buggy naming convention.

-- 
  "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/20110330125449.ga28...@khazad-dum.debian.net

Bug#620135: ITP: ViennaCL -- ViennaCL is a scientific computing library written in C++ based on OpenCL

2011-03-30 Thread Michael Wild 
Package: wnpp
Severity: wishlist
Owner: Michael Wild 


* Package name: ViennaCL
  Version : 1.1.1
  Upstream Author : Karl Rupp 
* URL : http://viennacl.sf.net
* License : Expat
  Programming Lang: C++
  Description : ViennaCL is a scientific computing library written in C++ 
based on OpenCL

The Vienna Computing Library (ViennaCL) is a scientific computing
library written in C++ and based on OpenCL. It allows simple, high-level
access to the vast computing resources available on parallel
architectures such as GPUs and is primarily focused on common linear
algebra operations (BLAS levels 1, 2 and 3) and the solution of large
systems of equations by means of iterative methods with optional
preconditioner.



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

throw away debs and source only uploads

2011-03-30 Thread Stefano Zacchiroli 
On Mon, Mar 28, 2011 at 03:37:05PM +0100, Mark Hymers wrote:
> Ok, the situation here is the following:

Thanks a lot for taking the time of clarifying.

> The main decision which needs to be made is whether, as a project, we
> want source only uploads or to throw away DD built non-all debs.
> There's not entire agreement amongst the ftpmasters about this (I err
> on the side of the source-only uploads to avoid making people waste
> time and bandwidth but that's not the only opinion).
 
> Once a decision is made, implementation is easy, but I'd like some
> form of consensus before we go down that route.

So, let me see if I can help out in shaping the discussion around this.
First of all my gut feeling is the same as Don's [1]. I've the
impression that throw away debs is a rather uncontroversial step to take
and that we could take independently from source only uploads.

  [1] http://lists.debian.org/debian-devel/2011/03/msg01063.html

Clearly that would not solve some of the issues that source only uploads
would solve, most notably the "wasted bandwidth" issue. At the same
time: 1) it won't be worse than the status quo in that respect either,
and 2) would be better than the status quo in terms of package
uniformity wrt their build environments.

I saw only one potential drawback in going forward with throw away debs,
namely the risk of doing some job to implement them and them throw it
away the day, potentially near, we further switch to source only
uploads. My interpretation of your mail is that this risk is pretty low,
as the involved work is low as well.  (Yes, I've also seen the various
interesting proposals of comparing metadata of uploaded packages against
those of rebuilt packages and I understand that implementing those would
require significantly more work. But none of those proposals seem to be
*requirements* to go ahead.)

If my gut feeling will be shown to be wrong on the consensus around
throw away debs (with evidence coming as angry replies to this mail), I
propose to have a poll on throw away debs.

Bottom line #1: I propose to go ahead and deploy throw away debs, as
soon as technically feasible.



> One objection to source-only is the perception that people will throw
> untested things at the buildds and see what sticks.  That strikes me
> as a social problem, but as a project we probably want to think how to
> handle it.

Regarding source only upload, well, it's tricky. There is the usual
tension about the principle desire of trusting every DD to do the right
thing and the reality-check observation that enabling people to upload
only sources *will* mean that some people will upload packages without
having even built them once; let's call this latter problem "developer
sloppiness".  (Shameless [academic] plug: developer sloppiness is fairly
common all over computer science. That's part of the reason why we have
developed over time programming languages which are more and more strict
in *forcing* developers to do the right™ thing, at least by default.)

The main use case I've seen mentioned on list to favor source only
uploads over throw away debs is that of "low bandwidth" or "bandwidth
limits". Most likely, that use case applies to very few people and the
vast majority of uploads could happen without suffering of those
problems.

To address developer sloppiness, sane defaults could be enough. If this
is the case, a solution that might work is a scheme in which source only
uploads are disallowed by default, but at the same time can be enabled
if the uploader really needs to. If the needed explicit step to have a
source only upload gets through is "costly" enough, sloppy developers
won't implement it (after all they are sloppy, aren't they?) and we
should be able to avoid a good deal of gratuitous additional FTBFS.

An implementation which might cut the deal can rely on lintian. We might
for instance have a lintian error which is triggered by a changes file
missing .deb files and have such an error be valid ground for automatic
rejection by dak. A maintainer who really needs to do a source only
upload for that package will simply have to add the proper override.
Bonus features: maintainers which rely "too much" on source only uploads
(assuming that can be defined...) can be easily spotted as the overrides
are in the archive. Drawback of this solution: overrides will be per
package and will have the tendency of stick around packages; that should
not be a big deal either, assuming the current defaults and recommended
practices of dpkg-buildpackage & friend will still be about building
binary packages by default.

The above is just an idea, little more than a brain-dump, for finding a
compromise among the real needs of people with bandwidth problem and the
social issues revolving around developer sloppiness.

Once more: it's material for discussion which IMHO should not be in the
way of the implementation of the throw away debs scheme.


Cheers.

-- 
Stefano Zacchiroli -o- PhD in Comp

/run support for wheezy?

2011-03-30 Thread Roger Leigh 
Given that Fedora are adopting /run, and it has been something
we have wanted in the past, is anyone working on implementing
/run in Debian?

http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
https://lwn.net/Articles/436012/


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

Top level directory /run added to Fedora/Suse

2011-03-30 Thread Anthony Towns 
Hi,

Via LWN I see:

> I just uploaded a new version of systemd into F15, which establishes a
> directory /run in the root directory.
> ...
> In the past weeks key people from the Debian, Suse, Ubuntu and Fedora
> camps (and others, too) discussed the whole issue forth and back, ...
> ...
> With this upload Fedora and Suse have already adopted /run now. Debian
> folks will suggest this for their coming release. Ubuntu has agreed with
> introducing /run as well.

 -- http://lwn.net/Articles/436012/

I hadn't seen any hint of this up 'til now, and with a quick peruse couldn't
find any posts. Are there any? If so, any urls?

Anyway, I'd like to give a +1000 to this, and offer my thanks to the
nameless Debianites who've pushed this forward. And hey, can we nominate the
Debian/Suse/Ubuntu/Fedora cabal^Wrepresentatives who've already made such
progress as the new FHS maintainers while we're at it? :)

Cheers,
aj

-- 
Anthony Towns

Re: /run support for wheezy?

2011-03-30 Thread Julien Cristau 
On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:

> Given that Fedora are adopting /run, and it has been something
> we have wanted in the past, is anyone working on implementing
> /run in Debian?
> 
> http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976

That seems to say "on Debian /lib/init/rw was introduced for the same
thing, but I'm using a different name just because I can".  What am I
missing?

Cheers,
Julien


-- 
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/20110330152955.gt3...@radis.liafa.jussieu.fr

Re: /run support for wheezy?

2011-03-30 Thread Tollef Fog Heen 
]] Julien Cristau 

| On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:
| 
| > Given that Fedora are adopting /run, and it has been something
| > we have wanted in the past, is anyone working on implementing
| > /run in Debian?
| > 
| > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976

Incidentially, I just sent a mail proposing this as a release goal.

| That seems to say "on Debian /lib/init/rw was introduced for the same
| thing, but I'm using a different name just because I can".  What am I
| missing?

It's a bit of an abuse of the /lib namespace.  It also outlines a plan
for how to get rid of /var/run and /var/lock long-term, something I
don't believe /lib/init/rw ever tried to.  It was just somewhere to
stuff random early data.

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

Re: throw away debs and source only uploads

2011-03-30 Thread The Fungi 
On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
[...]
> The above is just an idea, little more than a brain-dump, for
> finding a compromise among the real needs of people with bandwidth
> problem and the social issues revolving around developer
> sloppiness.
[...]

I expect part of the concern on both sides simply resolves around
conservation, doing "the right thing" as a project and not wasting
Internet/computing resources (I know bandwidth is much more of a
commodity these days, but lots of people are still instilled with
the careful principles of yesteryear).

One possible compromise which I think was already mentioned in one
of the earlier discussions (but now I can't find a reference) was to
initially attempt builds of source-only uploads on one arch and
delay building on the rest until it was proven not to FTBFS. This
strikes a balance between wasting buildd resources and not assuming
devs are irresponsibly sloppy (disclaimer: this was not my
impression of course, and IANADD anyway). It probably increases
latency for package entry into the archive, but any uploader
concerned about that can simply do a normal upload including their
locally-built binary packages to vouch for buildablity of the
source.
-- 
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }


-- 
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/20110330155231.go1...@yuggoth.org

Re: /run support for wheezy?

2011-03-30 Thread Roger Leigh 
On Wed, Mar 30, 2011 at 05:39:13PM +0200, Tollef Fog Heen wrote:
> ]] Julien Cristau 
> 
> | On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:
> | 
> | > Given that Fedora are adopting /run, and it has been something
> | > we have wanted in the past, is anyone working on implementing
> | > /run in Debian?
> | > 
> | > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
> 
> Incidentially, I just sent a mail proposing this as a release goal.
> 
> | That seems to say "on Debian /lib/init/rw was introduced for the same
> | thing, but I'm using a different name just because I can".  What am I
> | missing?
> 
> It's a bit of an abuse of the /lib namespace.  It also outlines a plan
> for how to get rid of /var/run and /var/lock long-term, something I
> don't believe /lib/init/rw ever tried to.  It was just somewhere to
> stuff random early data.

Exactly.  It also provides a place for people currently abusing the
/dev tmpfs, and using /etc as a writable location for cache files
(LVM2).

% ls -1d /dev/.*
/dev/.initramfs
/dev/.initramfs-tools
/dev/.mdadm
/dev/.udev

Once present, it should be easy to provide compatibility symlinks
for /lib/init/rw, /var/run and /var/lock.


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: MBF alert: packages with very long source / .deb filenames

2011-03-30 Thread gregor herrmann 
On Wed, 30 Mar 2011 11:56:22 +0100, Steve McIntyre wrote:

> >Right, that's certainly true for the lib.*-perl packages, and I
> >wouldn't know how we should rename them in a sane way.
> In the worst case that I'm looking at, I'm a little surprised by the
> names here on two fronts:
> libcgi-application-basic-plugin-bundle-perl_0.5.orig-CGI-Application-Plugin-ValidateRM-2-3.tar.gz
> 1. Why the "bundle" ?

Because the ftp-masters don't (or at least didn't) want small
packages in the archive.
From the packaging point of view we'd split them up immediately if
that was ok for them. Cf. #606411.
 
> 2. Why such a silly long name? What will happen if somebody comes
>along with another perl module to add to this bundle, but with a
>name twice as long? Does the source name for this tarball have to
>contain the whole of the bundle name?

As far as I understand source format v3 with multiple upstream
tarballs, the first part (up to .orig) can't be changed as it needs
to be the same as for the "main" package. [0] The second part (the
component) name is free-form, and as I said earlier, here's a bit of
room for us to shorten it (in this case e.g. from
CGI-Application-Plugin-ValidateRM-2-3 to ValidateRM).


Cheers,
gregor

[0] Although in this case the package name itself is made up and
could be shortend from libcgi-application-basic-plugin-bundle-perl to
something like libcgi-application-plugins-perl.

-- 
 .''`.   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: David Bowie: Tvc 15


signature.asc
Description: Digital signature

Re: throw away debs and source only uploads

2011-03-30 Thread Ben Hutchings 
On Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli wrote:
[...]
> Regarding source only upload, well, it's tricky. There is the usual
> tension about the principle desire of trusting every DD to do the right
> thing and the reality-check observation that enabling people to upload
> only sources *will* mean that some people will upload packages without
> having even built them once; let's call this latter problem "developer
> sloppiness".  (Shameless [academic] plug: developer sloppiness is fairly
> common all over computer science. That's part of the reason why we have
> developed over time programming languages which are more and more strict
> in *forcing* developers to do the right™ thing, at least by default.)
[...]

Someone (I forget who) previously suggested that a source-only changes
file should have to be accompanied by a build log.  This would need a
bit of infrastructure to file the build log away.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110330163345.gu2...@decadent.org.uk

Re: throw away debs and source only uploads

2011-03-30 Thread Lars Wirzenius 
On ke, 2011-03-30 at 17:33 +0100, Ben Hutchings wrote:
> Someone (I forget who) previously suggested that a source-only changes
> file should have to be accompanied by a build log.  This would need a
> bit of infrastructure to file the build log away.

Most uploads are done using dput or dupload. We could add code to them
to verify that there's binaries corresponding to the source that is
about to be built.

-- 
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/1301503405.11500.13.ca...@havelock.liw.fi

Re: new buildd dependency resolution breaks self depends?

2011-03-30 Thread Wesley W. Terpstra 
On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx  wrote:

> On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
> > If I may ask, for what purpose do the buildds have a special list of
> > packages above and beyond those in unstable?
>
> So that in case various packages have to be build in an order,
> where the seconds depends on the first being available and so on,
> that it doesn't take weeks to get them all build.  We would have
> to wait at least a dinstall before the next one could be build,
> assuming sometimes has the time to sign the package between
> dinstalls.
>
> It basicly just avoids a whole lot of delays.
>

Unfortunately, it seems also to add quite some delays in the self-compiling
case. :-/ Each time a buildd finishes, that buildd's Packages file gets
updated due to the completed binary upload and all other buildds go back
into the BD-Uninstallable state. (I assume this also means the package loses
its place in line on the busy buildd queues)

I wonder if the same rules applied to the unstable package list (don't
include the all for a package whose any is not done) could be applied also
to the buildd's Packages?

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Luk Claes 
Hi

Below an update of the release goals I advocated and some thoughts on
others.

> Release Goals
> -
> As a first step towards establishing release goals for wheezy, we will
be reviewing
> each of the goals which we had for squeeze [RDO:SGoals] to see which
have been achieved and which
> may no longer be relevant for other reasons.
>
> If you are listed as the proponent for a goal in the above list,
please feel free to
> provide a status update on progress towards completing it and whether
you believe it is
> relevant for the wheezy cycle.  You can also e-mail us to propose a
new goal, including
> a description of the goal and an indication of how progress on the
issues may be tracked
> (e.g. a pointer to a set of appropriate user-tagged bugs).

# bootperformance
  Advocate: Petter Reinholdsen and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/BootPerformance

The main part of this goal was achieved, though there are some possible
improvements both regarding boot reliability and boot performance that
could still be aimed for.

Regarding reliability I'm doing some work regarding NFS, though one of
the main outstanding issues is the race between availability of the
network devices and the end of the network init script AFAICS. It would
also not be a bad idea to have a discussion on whether the default init
system should change to one that is more suitable to guarantee the
reliability of the boot like upstart or systemd.

Regarding boot performance there is quite some work done by Ubuntu in
different packages, so maybe it would not be bad to have a look at how
Ubuntu and Debian could get more in sync on that.

# package quality
  Advocate: Holger Levsen and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality

This is a never ending goal of sustaining our packages quality by
improving our tests and following up closely... so needless to say that
I would still advocate this one.

# remove obsolete libraries
  Advocate: Barry deFreese and Luk Claes
  State: confirmed
  Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs

This worked quite well and should continue so we can get rid of obsolete
libraries IMHO. One of the main candidates are the old db libraries,
though there are also still some old gnome libraries and without doubt
others.

> We're also after new goals! I know that expressions of interest in
multiarch and
> tdebs have already been indicated, but if you have something you would
want to
> see happen for Wheezy, please let us know. The release team itself will be
> suggesting some as part of the review above.

I'm definitely in favour of having multiarch finally happen!

For the IPv6 and LFS legacy release goals I think it would be best if we
would welcome massive (automatic?) tests to find all of the outstanding
issues and get them fixed finally!

I would welcome a review of essential, required and standard though I
don't know if many would welcome such an initiative which could
potentially have quite some impact without much visible gain. Anyway
it's something which should happen in the beginning of the cycle (after
a discussion with both the involved maintainers as well as the
developers body at large) or not at all 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/4d936684.2050...@debian.org

Re: new buildd dependency resolution breaks self depends?

2011-03-30 Thread Kurt Roeckx 
On Wed, Mar 30, 2011 at 06:45:50PM +0200, Wesley W. Terpstra wrote:
> On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx  wrote:
> 
> > On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
> > > If I may ask, for what purpose do the buildds have a special list of
> > > packages above and beyond those in unstable?
> >
> > So that in case various packages have to be build in an order,
> > where the seconds depends on the first being available and so on,
> > that it doesn't take weeks to get them all build.  We would have
> > to wait at least a dinstall before the next one could be build,
> > assuming sometimes has the time to sign the package between
> > dinstalls.
> >
> > It basicly just avoids a whole lot of delays.
> >
> 
> Unfortunately, it seems also to add quite some delays in the self-compiling
> case. :-/ Each time a buildd finishes, that buildd's Packages file gets
> updated due to the completed binary upload and all other buildds go back
> into the BD-Uninstallable state. (I assume this also means the package loses
> its place in line on the busy buildd queues)

That actually doesn't seem to be that case.  I think ftp-master
just removed the old binary from unstable, and didn't give the
buildd's the chance to actually build against the old version,
and we're screwed now.

I suggest you ask them to restore the old binaries in unstable,
(and remove the arch all) packages for those arches it's not
yet build/uploaded for.


Kurt


-- 
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/20110330172213.ga32...@roeckx.be

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Josselin Mouette 
Le mercredi 30 mars 2011 à 19:21 +0200, Luk Claes a écrit :
> # remove obsolete libraries
>   Advocate: Barry deFreese and Luk Claes
>   State: confirmed
>   Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
> 
> This worked quite well and should continue so we can get rid of obsolete
> libraries IMHO. One of the main candidates are the old db libraries,
> though there are also still some old gnome libraries and without doubt
> others.

I fully support this, and I’d like indeed to remove some more obsolete
libraries for wheezy. We should start with HAL and gnome-vfs, which are
big things. Along the way I’d like to get rid of the least used GTK2
libraries in favor of their GTK3 counterpart.

-- 
 .''`.
: :' : “You would need to ask a lawyer if you don't know
`. `'   that a handshake of course makes a valid contract.”
  `---  J???rg Schilling


--
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/1301506702.6014.60.camel@pi0307572

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Michael Tautschnig 
Hi all,

[...]

> # package quality
>   Advocate: Holger Levsen and Luk Claes
>   State: confirmed
>   Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
> 
> This is a never ending goal of sustaining our packages quality by
> improving our tests and following up closely... so needless to say that
> I would still advocate this one.
> 
[...]

I would advocate the idea behind this goal as well, yet I think as-is this isn't
a very useful goal: how would we ever measure its achievement? To this end, I
think, we need to give a much more precise definition of how we intend to
measure "quality". For instance, we could fix lintian version x.y.z and state
that we want to have 0 errors at the time of release. Similarly for piuparts. Or
a bugs per package ratio. All of these are measurable and can be checked for,
although of course they only give a very limited notion of "quality". 

Best regards,
Michael



pgpxqPAt78sbC.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Michael Biebl 
Am 30.03.2011 19:38, schrieb Josselin Mouette:
> Le mercredi 30 mars 2011 à 19:21 +0200, Luk Claes a écrit :
>> # remove obsolete libraries
>>   Advocate: Barry deFreese and Luk Claes
>>   State: confirmed
>>   Wiki: http://wiki.debian.org/ReleaseGoals/RemoveOldLibs
>>
>> This worked quite well and should continue so we can get rid of obsolete
>> libraries IMHO. One of the main candidates are the old db libraries,
>> though there are also still some old gnome libraries and without doubt
>> others.
> 
> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs,

HAL removal is already in progress, see [1]. Actually I've been working on that
for some time already. I wouldn't object obviously making that a release goal.

It seems certainly doable in time for wheezy. The only real blocker I currently
see, is our kfreebsd ports, which still rely on hal e.g. in GVFS, which is a
central part of the GNOME stack.

Michael


[1] http://wiki.debian.org/HALRemoval


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Michael Biebl 
Am 30.03.2011 19:21, schrieb Luk Claes:
> Regarding reliability I'm doing some work regarding NFS, though one of
> the main outstanding issues is the race between availability of the
> network devices and the end of the network init script AFAICS. It would
> also not be a bad idea to have a discussion on whether the default init
> system should change to one that is more suitable to guarantee the
> reliability of the boot like upstart or systemd.
> 

...

> I would welcome a review of essential, required and standard though I
> don't know if many would welcome such an initiative which could
> potentially have quite some impact without much visible gain. Anyway
> it's something which should happen in the beginning of the cycle (after
> a discussion with both the involved maintainers as well as the
> developers body at large) or not at all IMHO.

One of the steps required to make it possible to test alternative init systems
(on a wider scale) is to get the Essential flag removed from sysvinit (and
possibly initscripts), so systemd and upstart can be installed without force.
 This has been on my wishlist for squeeze and we should definitely get the
necessary changes into wheezy as early as possible during the development cycle.
Dunno if this warrants a separate release goal though.


Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Marco d'Itri 
On Mar 30, Luk Claes  wrote:

> For the IPv6 and LFS legacy release goals I think it would be best if we
> would welcome massive (automatic?) tests to find all of the outstanding
> issues and get them fixed finally!
I fear that the major outstanding issue is ifupdown, which basically
does not support non-trivial dual stacked configurations and needs a
serious redesign.
e.g. vlan/bridging if-*.d scripts are run for every AFI.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Christian PERRIER 
Quoting Josselin Mouette (j...@debian.org):

> I fully support this, and I’d like indeed to remove some more obsolete
> libraries for wheezy. We should start with HAL and gnome-vfs, which are
> big things. Along the way I’d like to get rid of the least used GTK2
> libraries in favor of their GTK3 counterpart.

How about dropping defoma ?

The pkg-fonts team did that on fonts we maintain, but there are many
other fonts packages (some of them somehow abandoned or loosely
maintained) that need to do it.




signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Roger Leigh 
On Tue, Mar 29, 2011 at 10:51:02AM +0100, Neil McGovern wrote:
> Release Goals
> -
> As a first step towards establishing release goals for wheezy, we will
> be reviewing each of the goals which we had for squeeze [RDO:SGoals] to
> see which have been achieved and which may no longer be relevant for
> other reasons.

Here's a list of things I'd like to see in squeeze, though I probably
won't have time to push them all myself:

• C.UTF-8 provided by default, to provide a guaranteed present
  standard C locale (#609306).  Looks like this is now in eglibc
  (2.13-0exp3) in experimental, so the main remaining task is to
  convert existing packages (lintian etc.) which currently generate
  their own locales and/or use other locales to use C.UTF-8.
  Thanks to Aurelien Jarno for pushing this.

  As a followup, I would like to get the UTF-8 codeset and collation
  hardcoded in libc6 directly and sharable by all UTF-8 locales to
  reduce startup time and needless duplication (due to using a separate
  codeset facet for each locale loaded).  This would allow the
  subsequent creation of a real "C" locale using a UTF-8 codeset.
  Needs some digging into the eglibc locale code though.

• /run (as being currently discussed)

  Easy enough to add the top-level directory.  We do however need to
  cope with handling upgrades, compatibility bind mounts and/or
  symlinks etc.  I've been working on an initscripts patch to handle
  this, but it will need wider discussion and testing.  Given the
  historical usage of /var/run and /var/lock, we will need to keep
  compatibility links in place for the foreseable future, if not
  indefinitely, plus compatibility /lib/init/rw link to allow for
  squeeze upgrades.

• dpkg-buildpackage support for build-arch and build-indep by default

  AFAICT requires a mechanism to autodetect the presence of the targets
  in the rules file to allow their use if present, falling back to the
  build target if absent.

  This is a long standing deficiency in our toolchain, which is
  preventing correct support for Build-Depends-Indep/
  Build-Conflicts-Indep in autobuilding, since the build target may or
  may not require Build-Depends-Indep when doing binary-only builds
  (and vice versa).  Having the correct separation will permit sane
  and reliable build dependency installation.  This will become more
  of an issue with arch-all autobuilding.

  This is something we've wanted for years, but which has continually
  been stalled by issues doing the migration.  We've got support for
  build-arch and build-indep in cdbs and dh, which makes over 50% of
  the archive support them today.  Developers can add the targets
  today, and add

build: build-arch build-indep

  to have their package build with both current and future versions of
  the toolchain, with the appropriate bits being doing in each rule.
  I've proposed a change to Policy to change this from "may be provided"
  to "must" (#604397).

  Some previous proposals have called for this to be enabled if >= a
  certain Standards-Version is supported, or a flag in Build-Options
  is enabled by the package.  However, we want build-arch and
  build-indep to be used *by default*.  The maintainer should not need
  to take additional, explict, action in order to have them used.  I
  therefore think autodetection is the most useful approach.

  In the meantime, we should encourage maintainers to pre-emptively
  adopt build-arch and build-indep, and could patch lintian to warn
  if not present.

• Read-only root

  Depends on /run.  Having /run will allow remaining writable files
  under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
  Identifying and fixing/removing packages writing to /etc during
  their normal operation would be a worthy release goal.

  This will make Debian more secure to run, easier to deploy in a
  cluster or netboot environment (no writable image overlay required),
  keeping dpkg-managed filesystems completely read-only during normal
  operation (other than /var).

• /usr "removal"

  We should allow the installation and running of a system with no
  /usr (where /usr is a symlink to / for backward compatibility).

  Previously discussed on -devel.  Initially, this is intended to be
  optional, keeping all dpkg-managed files on a single filesystem.
  In the future, we would have the option of dropping /usr entirely.

  Work needing doing: identification and removal of duplicate paths
  under / and /usr.  If we want to support this on upgrades as well
  as new installs, upgrades need considering here as well.  Support
  in debian-installer for disabling /usr would also be required.
  Also, tools such as dpkg-shlibdeps, ld etc. would need checking
  to make sure that building on such a system still results in
  packages which are installable on old-style split systems, e.g.
  when generating shlibs files etc.


I'm sure I'll have more to come!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debia

Bug#620180: ITP: liblwp-protocol-https-perl -- https driver for LWP::UserAgent

2011-03-30 Thread Nicholas Bamber 

Package: wnpp
Owner: Nicholas Bamber 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: liblwp-protocol-https-perl
  Version : 6.02
  Upstream Author : Gisle Aas 
* URL : http://search.cpan.org/dist/LWP-Protocol-https/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : https driver for LWP::UserAgent

The LWP::Protocol::https module provide support for using https schemed URLs
with LWP. LWP::Protocol::https is a plug-in to the LWP protocol handling, so
you don't use it directly. Once the module is installed LWP is able to 
access

sites using HTTP over SSL/TLS.

If hostname verification is requested by LWP::UserAgent's ssl_opts, and
neither SSL_ca_file nor SSL_ca_path is set, then SSL_ca_file is implied 
to be

the one provided by Mozilla::CA. If the Mozilla::CA module isn't available
SSL requests will fail. Either install this module, set up an alternative
SSL_ca_file or disable hostname verification.

This module used to be bundled with the libwww-perl, but it was unbundled in
v6.02 in order to be able to declare its dependencies properly for the CPAN
tool-chain. Applications that need https support can just declare their
dependency on LWP::Protocol::https and will no longer need to know what
underlying modules to install.



--
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/4d938237.7070...@periapt.co.uk

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Michael Tautschnig 
[...]
> • Read-only root
> 
>   Depends on /run.  Having /run will allow remaining writable files
>   under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
>   Identifying and fixing/removing packages writing to /etc during
>   their normal operation would be a worthy release goal.
> 
>   This will make Debian more secure to run, easier to deploy in a
>   cluster or netboot environment (no writable image overlay required),
>   keeping dpkg-managed filesystems completely read-only during normal
>   operation (other than /var).
> 
[...]

Here's an obviously incomplete list of such files, from a fairly comprehensive
desktop installation. I've taken these from my integrit configuration for a
lenny (!) system - I'd love not to be in need for such a list of exceptions.

/etc/aumixrc
/etc/mtab
/etc/motd
/etc/adjtime
/etc/resolv.conf
/etc/qt3/qt_plugins_3.3rc
/etc/network/run/ifstate
/etc/hotplug/.run/net.enable
/etc/cups/ppd/
/usr/share/ppd/custom/
/etc/cups/classes.conf
/etc/cups/printers.conf
/etc/cups/printers.conf.O
/etc/cups/cupsd.conf
/etc/printcap
/etc/lvm/cache/.cache
/etc/openvpn/openvpn-status.log
/etc/blkid.tab
/etc/blkid.tab.old
/etc/samba/dhcp.conf
/etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)

Hope this helps,
Michael



pgpnWeuDOjbXO.pgp
Description: PGP signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Ben Hutchings 
On Wed, Mar 30, 2011 at 08:19:52PM +0200, Marco d'Itri wrote:
> On Mar 30, Luk Claes  wrote:
> 
> > For the IPv6 and LFS legacy release goals I think it would be best if we
> > would welcome massive (automatic?) tests to find all of the outstanding
> > issues and get them fixed finally!
> I fear that the major outstanding issue is ifupdown, which basically
> does not support non-trivial dual stacked configurations and needs a
> serious redesign.
> e.g. vlan/bridging if-*.d scripts are run for every AFI.

I agree that ifupdown is broken, but how is this connected to the
IPv6 goal?  For IPv6 it is at least using iproute2 and not bad old
ifconfig...

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110330195016.gv2...@decadent.org.uk

Very urgent

2011-03-30 Thread Koudou Michel Gbagbo 

Hi,
It is my humble pleasure to introduce myself to you. However, I would need your 
attention for a moment. My name is Koudou Michel Gbagbo, age 29 the son of 
president Laurent Gbagbo, I am from Abidjan (Côte d'Ivoire) West Africa, I 
would like to use your relationship with me to pull my wealth out of the future 
problems my father is creating for himself and the family name. My father lost 
the election to his rival and refused to step down from power resisting all 
international pressures and warnings. If I don't safe guide my account to 
another name, soon I may be at my own risk because government will freeze every 
bank account in our family last name including properties.
I promise you will not regret this relationship with me. If you can help me 
with this, please let me Know.
Thank you
Koudou Michel Gbagbo


--
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/qq6kirfo5o00glqupdukpqlatuae68fixhktqwug7...@yahoo.co.jp

Re: new buildd dependency resolution breaks self depends?

2011-03-30 Thread Goswin von Brederlow 
Kurt Roeckx  writes:

> On Wed, Mar 30, 2011 at 06:45:50PM +0200, Wesley W. Terpstra wrote:
>> On Tue, Mar 29, 2011 at 8:03 PM, Kurt Roeckx  wrote:
>> 
>> > On Tue, Mar 29, 2011 at 07:54:59PM +0200, Wesley W. Terpstra wrote:
>> > > If I may ask, for what purpose do the buildds have a special list of
>> > > packages above and beyond those in unstable?
>> >
>> > So that in case various packages have to be build in an order,
>> > where the seconds depends on the first being available and so on,
>> > that it doesn't take weeks to get them all build.  We would have
>> > to wait at least a dinstall before the next one could be build,
>> > assuming sometimes has the time to sign the package between
>> > dinstalls.
>> >
>> > It basicly just avoids a whole lot of delays.
>> >
>> 
>> Unfortunately, it seems also to add quite some delays in the self-compiling
>> case. :-/ Each time a buildd finishes, that buildd's Packages file gets
>> updated due to the completed binary upload and all other buildds go back
>> into the BD-Uninstallable state. (I assume this also means the package loses
>> its place in line on the busy buildd queues)
>
> That actually doesn't seem to be that case.  I think ftp-master
> just removed the old binary from unstable, and didn't give the
> buildd's the chance to actually build against the old version,
> and we're screwed now.
>
> I suggest you ask them to restore the old binaries in unstable,
> (and remove the arch all) packages for those arches it's not
> yet build/uploaded for.
>
>
> Kurt

It used to be that any _all.deb uploaded was added to all archs
directly. Under that setup the build would never have succeeded.

Having it suceed with a delay between upload and builds is an
improvement already.

MfG
Goswin


-- 
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/87pqp8s6i4.fsf@frosties.localnet

Re: /run support for wheezy?

2011-03-30 Thread Goswin von Brederlow 
Tollef Fog Heen  writes:

> ]] Julien Cristau 
>
> | On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:
> | 
> | > Given that Fedora are adopting /run, and it has been something
> | > we have wanted in the past, is anyone working on implementing
> | > /run in Debian?
> | > 
> | > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
>
> Incidentially, I just sent a mail proposing this as a release goal.
>
> | That seems to say "on Debian /lib/init/rw was introduced for the same
> | thing, but I'm using a different name just because I can".  What am I
> | missing?
>
> It's a bit of an abuse of the /lib namespace.  It also outlines a plan
> for how to get rid of /var/run and /var/lock long-term, something I
> don't believe /lib/init/rw ever tried to.  It was just somewhere to
> stuff random early data.

What subdirs will we have then?

/run/run  (formerly /var/run)
/run/init (formerly /lib/init/rw)
/run/lock (formerly /var/lock)

or will one of the formerlies become the /run and the other subdirs. or
will /var/run and /lib/init/rw be merged into just /run and /run/lock
for locks?

Depending on that upgrade options change so we should nail that down
first.

MfG
Goswin


-- 
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/87lizws618.fsf@frosties.localnet

"expected stable-updates but got squeeze-updates"

2011-03-30 Thread Christoph Anton Mitterer 
Hi.


Using the following in sources.list:
deb ftp://security.debian.org/debian-security/ stable/updates main contrib
non-free
deb-src ftp://security.debian.org/debian-security/ stable/updates main
contrib non-free

I always get warnings like these:
>W: Conflicting distribution: ftp://debian.mirror.lrz.de stable-updates
Release (expected stable-updates but got squeeze-updates)
when updating.

Is this a false warning of apt[itude] or a problem on the ftp-servers?


Cheers,
Chris.


-- 
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/a1f8761144647ef82f4c50dbc2bd7...@imap.dd24.net

Re: "expected stable-updates but got squeeze-updates"

2011-03-30 Thread Adam D. Barratt 
On Wed, 2011-03-30 at 20:45 +, Christoph Anton Mitterer wrote:
> Using the following in sources.list:
> deb ftp://security.debian.org/debian-security/ stable/updates main contrib
> non-free
> deb-src ftp://security.debian.org/debian-security/ stable/updates main
> contrib non-free

The above is not related to the warning below.  Compare the server names
and suite names between the two.

> I always get warnings like these:
> >W: Conflicting distribution: ftp://debian.mirror.lrz.de stable-updates
> Release (expected stable-updates but got squeeze-updates)
> when updating.
> 
> Is this a false warning of apt[itude] or a problem on the ftp-servers?

It's not really either of those, but rather due to your sources.list
containing an entry for debian-mirror.lrz.de for the "stable-updates"
suite.  However, the suite is actually called "squeeze-updates", and
that's therefore what appears in the Release file.  Changing
sources.list to point at squeeze-updates instead should make the warning
go away.

Regards,

Adam


-- 
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/1301521131.12508.4061.ca...@hathi.jungle.funky-badger.org

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Peter Samuelson 

[Roger Leigh]
>   As a followup, I would like to get the UTF-8 codeset and collation
>   hardcoded in libc6 directly and sharable by all UTF-8 locales to
>   reduce startup time and needless duplication

Collation is not just a function of character set, it's quite
locale-dependent.  Not sure if the character class tables (
functions, and the [:foo:] posix regex classes) could be shared across
UTF-8 locales.  I rather suspect not.

When you take out collation and possibly character classes, I'm not
sure whether there's anything in the UTF-8 locales left to hardcode
into libc.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.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/20110330213930.ga3...@p12n.org

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Marco d'Itri 
On Mar 30, Ben Hutchings  wrote:

> > > For the IPv6 and LFS legacy release goals I think it would be best if we
> > > would welcome massive (automatic?) tests to find all of the outstanding
> > > issues and get them fixed finally!
> > I fear that the major outstanding issue is ifupdown, which basically
> > does not support non-trivial dual stacked configurations and needs a
> > serious redesign.
> > e.g. vlan/bridging if-*.d scripts are run for every AFI.
> I agree that ifupdown is broken, but how is this connected to the
> IPv6 goal?  For IPv6 it is at least using iproute2 and not bad old
> ifconfig...
The problem is with all features implemented by external if-*.d scripts.
If e.g. a bridge is created by the first defined afi, the second script
will fail. And if it does not fail on up then everything will still
break on a down event, when the script run by the first AFI will destroy
the interface and ifupdown will be able to remove the IP address of the
second AFI.
Bugs were opened long ago, but there is no interest/manpower to fix
them (which is not surprising if you have ever looked at the ifupdown
source).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Goswin von Brederlow 
Michael Tautschnig  writes:

> [...]
>> • Read-only root
>> 
>>   Depends on /run.  Having /run will allow remaining writable files
>>   under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).
>>   Identifying and fixing/removing packages writing to /etc during
>>   their normal operation would be a worthy release goal.
>> 
>>   This will make Debian more secure to run, easier to deploy in a
>>   cluster or netboot environment (no writable image overlay required),
>>   keeping dpkg-managed filesystems completely read-only during normal
>>   operation (other than /var).
>> 
> [...]
>
> Here's an obviously incomplete list of such files, from a fairly comprehensive
> desktop installation. I've taken these from my integrit configuration for a
> lenny (!) system - I'd love not to be in need for such a list of exceptions.

I'm running a small server with squeeze (some beta but it won't have
become worse) with read-only / instaled that way from DI. Only needed
minimal fixes to work properly. Namely:

> /etc/mtab

link to /proc/mounts (manually)

I think this is going to be the default in the future but for some
reason wasn't added before squeeze froze.

> /etc/motd
> /etc/adjtime
> /etc/resolv.conf

No problems with those three. Network is configured static so dhcp-client
doesn't rewrite resolv.conf. The resolvconf package fixes the
resolv.conf write problem with dhcp-client and read-only /, right?

> /etc/network/run/ifstate

linked to /dev/shm (automatic if /dev/shm exists during install, so
purge + reinstall of ifupdwon fixes this)

Patch to use /lib/init/rw unconditionally on new installs is pending (as
seen on irc today).

> /etc/lvm/cache/.cache

Configurable in /etc/lvm/lvm.conf. If /run is adapted in debian then
changing the default location shouldn't be a problem.

> /etc/blkid.tab
> /etc/blkid.tab.old

hmm, don't have a problem with that. Shouldn't using lvm trigger that?


While read-only / does not (yet) quite work out of the box it is already
easily configurable that way. At least for a simple server.

I think it would be a worthy release goal to have it work out of the box
and even have a read-only / as a default template in Debian-Installer.

Other than the above one additional config is verry usefull:

$ cat /etc/apt/apt.conf.d/00read-only 
DPkg {
// Auto re-mounting of a readonly /usr
Pre-Invoke { "mount -o remount,rw /"; };
Pre-Invoke { "mount -o remount,rw /usr"; };
Post-Invoke { "mount -o remount,ro /usr || true"; };
Post-Invoke { "mount -o remount,ro / || true"; };
};


> /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)

Don't have that. Fix denyhosts to link that to /var/ (or /run when we
have it).

> Hope this helps,
> Michael

MfG
Goswin


-- 
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/87d3l8s1w7.fsf@frosties.localnet

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Luca Capello 
Hi there!

On Wed, 30 Mar 2011 21:09:17 +0200, Roger Leigh wrote:
> • Read-only root
>
>   Depends on /run.  Having /run will allow remaining writable files
>   under /etc to be moved (/etc/mtab, LVM2 cache, CUPS for starters).

For LVM2 there are at least two bugs:

  
  

This issue was also discussed for etckeeper's ignore list:

  

For CUPS, feel free to try to convince upstream:

  

>   Identifying and fixing/removing packages writing to /etc during
>   their normal operation would be a worthy release goal.

I added the packages above to the Debian wiki:

  

Thx, bye,
Gismo / Luca


pgpRz5ExIeiy6.pgp
Description: PGP signature

Re: "expected stable-updates but got squeeze-updates"

2011-03-30 Thread Christoph Anton Mitterer 
On Wed, 2011-03-30 at 22:38 +0100, Adam D. Barratt wrote:
> On Wed, 2011-03-30 at 20:45 +, Christoph Anton Mitterer wrote:
> > Using the following in sources.list:
> > deb ftp://security.debian.org/debian-security/ stable/updates main contrib
> > non-free
> > deb-src ftp://security.debian.org/debian-security/ stable/updates main
> > contrib non-free
> 
> The above is not related to the warning below.  Compare the server names
> and suite names between the two.
Why not? It's the place where I set the suite name?!


> It's not really either of those, but rather due to your sources.list
> containing an entry for debian-mirror.lrz.de for the "stable-updates"
> suite.  However, the suite is actually called "squeeze-updates", and
> that's therefore what appears in the Release file.  Changing
> sources.list to point at squeeze-updates instead should make the warning
> go away.
But then, why do we have those symlinks at all?
And it's quite handy IMHO that one can just use stable and get the
current stable suite.
The same should work for the volatile replacement.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: /run support for wheezy?

2011-03-30 Thread Roger Leigh 
On Wed, Mar 30, 2011 at 10:32:51PM +0200, Goswin von Brederlow wrote:
> Tollef Fog Heen  writes:
> 
> > ]] Julien Cristau 
> >
> > | On Wed, Mar 30, 2011 at 16:20:10 +0100, Roger Leigh wrote:
> > | 
> > | > Given that Fedora are adopting /run, and it has been something
> > | > we have wanted in the past, is anyone working on implementing
> > | > /run in Debian?
> > | > 
> > | > http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976
> >
> > Incidentially, I just sent a mail proposing this as a release goal.
> >
> > | That seems to say "on Debian /lib/init/rw was introduced for the same
> > | thing, but I'm using a different name just because I can".  What am I
> > | missing?
> >
> > It's a bit of an abuse of the /lib namespace.  It also outlines a plan
> > for how to get rid of /var/run and /var/lock long-term, something I
> > don't believe /lib/init/rw ever tried to.  It was just somewhere to
> > stuff random early data.
> 
> What subdirs will we have then?
> 
> /run/run  (formerly /var/run)
> /run/init (formerly /lib/init/rw)
> /run/lock (formerly /var/lock)
> 
> or will one of the formerlies become the /run and the other subdirs. or
> will /var/run and /lib/init/rw be merged into just /run and /run/lock
> for locks?

I've filed a bug (#620191) against initscripts containing a proposed
patch for this.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620191

/var/run (→ /run)
/var/lock (→ /run/lock)
/lib/init/rw (→ /run/init)
/dev/.* (→ /run/*)
/dev/shm/.* (→ /run/*)
writable files under /etc (→ /run/*)

> Depending on that upgrade options change so we should nail that down
> first.

The bug report and attached patch highlight some of the issues
for upgrades/new installs.  The patch isn't yet fully complete;
further discussion on how best to handle upgrades would be useful.

The changelog in the patch has a few items marked with TODO which
need more detailed specification.  Hopefully we can get /run
going fairly soon, once these are ironed out.


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: "expected stable-updates but got squeeze-updates"

2011-03-30 Thread Adam D. Barratt 
On Thu, 2011-03-31 at 00:10 +0200, Christoph Anton Mitterer wrote:
> On Wed, 2011-03-30 at 22:38 +0100, Adam D. Barratt wrote:
> > On Wed, 2011-03-30 at 20:45 +, Christoph Anton Mitterer wrote:
> > > Using the following in sources.list:
> > > deb ftp://security.debian.org/debian-security/ stable/updates main contrib
> > > non-free
> > > deb-src ftp://security.debian.org/debian-security/ stable/updates main
> > > contrib non-free
> > 
> > The above is not related to the warning below.  Compare the server names
> > and suite names between the two.
> Why not? It's the place where I set the suite name?!

Because security.debian.org is not debian-mirror.lrz.de.  The entries
above are for security.debian.org, whereas the error message you quoted
was for an entry containing debian-mirror.lrz.de; the entries for
security are not what's causing your error message.

> > It's not really either of those, but rather due to your sources.list
> > containing an entry for debian-mirror.lrz.de for the "stable-updates"
> > suite.  However, the suite is actually called "squeeze-updates", and
> > that's therefore what appears in the Release file.  Changing
> > sources.list to point at squeeze-updates instead should make the warning
> > go away.
> But then, why do we have those symlinks at all?
> And it's quite handy IMHO that one can just use stable and get the
> current stable suite.

It's also not universally agreed to be a good idea, as once a new stable
release occurs, your next "apt-get update" will suddenly pull in an
entirely new release's package lists, which isn't generally what you
want.

However, having "squeeze" in sources.list whilst the Release file
contains "stable" works okay, so I assume apt is managing the
translation internally in that case.  If it doesn't do so when the
Release file contains a codename then this is likely to become a more
general problem in future, given that ftp-master would like to move the
archive to being codename-based internally.

Regards,

Adam


-- 
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/1301523849.12508.4212.ca...@hathi.jungle.funky-badger.org

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Serafeim Zanikolas 
On Wed, Mar 30, 2011 at 07:21:08PM +0200, Luk Claes wrote [edited]:
> Below an update of the release goals I advocated and some thoughts on
> others.
[..]
> For the IPv6 and LFS legacy release goals I think it would be best if we

A minor aspect of ipv6 support, is for maintainer scripts to be able to
configure more than one entry per service in inetd.conf (one for ipv4 and
another for ipv6; eg. #527397). This issue is part of the motivation for
DEP9 (for which I've yet to receive any feedback).

-- 
Every great idea is worthless without someone to do the work. --Neil Williams


-- 
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/20110330222445.GC23664@mobee

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Ben Hutchings 
On Thu, 2011-03-31 at 00:01 +0200, Marco d'Itri wrote:
> On Mar 30, Ben Hutchings  wrote:
> 
> > > > For the IPv6 and LFS legacy release goals I think it would be best if we
> > > > would welcome massive (automatic?) tests to find all of the outstanding
> > > > issues and get them fixed finally!
> > > I fear that the major outstanding issue is ifupdown, which basically
> > > does not support non-trivial dual stacked configurations and needs a
> > > serious redesign.
> > > e.g. vlan/bridging if-*.d scripts are run for every AFI.
> > I agree that ifupdown is broken, but how is this connected to the
> > IPv6 goal?  For IPv6 it is at least using iproute2 and not bad old
> > ifconfig...
> The problem is with all features implemented by external if-*.d scripts.

Still don't see the specific connection to IPv6.

> If e.g. a bridge is created by the first defined afi, the second script
> will fail. And if it does not fail on up then everything will still
> break on a down event, when the script run by the first AFI will destroy
> the interface and ifupdown will be able to remove the IP address of the
> second AFI.
> Bugs were opened long ago, but there is no interest/manpower to fix
> them (which is not surprising if you have ever looked at the ifupdown
> source).

Sadly I am already overcommitted.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Processed: reassign 620133 to general

2011-03-30 Thread Debian Bug Tracking System 
Processing commands for cont...@bugs.debian.org:

> reassign 620133 general
Bug #620133 [qa.debian.org] qa.debian.org: auto-ethernet dhcp after dsl-box 
dont connectet sometimes. no prob with other os
Bug reassigned from package 'qa.debian.org' to 'general'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
620133: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620133
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.130152414814137.transcr...@bugs.debian.org

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Roger Leigh 
On Wed, Mar 30, 2011 at 04:39:30PM -0500, Peter Samuelson wrote:
> 
> [Roger Leigh]
> >   As a followup, I would like to get the UTF-8 codeset and collation
> >   hardcoded in libc6 directly and sharable by all UTF-8 locales to
> >   reduce startup time and needless duplication
> 
> Collation is not just a function of character set, it's quite
> locale-dependent.  Not sure if the character class tables (
> functions, and the [:foo:] posix regex classes) could be shared across
> UTF-8 locales.  I rather suspect not.

Maybe I'm just thinking of ctype.  I thought that (possibly due to
having __STDC_ISO_10646__) the character classes were identical across
all locales.  Collation is probably different.

> When you take out collation and possibly character classes, I'm not
> sure whether there's anything in the UTF-8 locales left to hardcode
> into libc.

There's the actual charmap (localedata/charmaps/UTF-8), which is
big and well worth sharing between locales irrespective of
hardcoding.  Looking at it again, I only see the C ctype hardcoded;
not the charmap, so maybe it's autogenerated or not even hardcoded
(since it's a 1:1 ASCII:UCS mapping for C).  It would be easier to
grok what's going on if it wasn't so hideously complex and
undocumented!


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: throw away debs and source only uploads

2011-03-30 Thread Paul Wise 
I definitely agree we want to throw away developer-built debs (arch
all & arch any) in almost all situations.

I don't think I would want the lintian solution for source-only
uploads, I would prefer something on a per-upload basis that requires
an explicit human decision per-upload rather than something that can
be scripted away. It is also important to have an audit trail for
this.

Maybe a mail bot on ftp-master that a developer needs to mail before
the upload will be accepted. The overrides could be published on the
ftp-master website and replies to them be CCed to -devel or another
list.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/AANLkTinjBCS0eR+oiTXVbiTG_fFt2RAWb+07QP=t=g...@mail.gmail.com

Re: throw away debs and source only uploads

2011-03-30 Thread Russ Allbery 
Paul Wise  writes:

> I definitely agree we want to throw away developer-built debs (arch all
> & arch any) in almost all situations.

> I don't think I would want the lintian solution for source-only uploads,
> I would prefer something on a per-upload basis that requires an explicit
> human decision per-upload rather than something that can be scripted
> away. It is also important to have an audit trail for this.

We could add another queue similar to the DELAYED queues, maybe.

-- 
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/877hbgkxnc@windlord.stanford.edu

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Paul Wise 
On Thu, Mar 31, 2011 at 2:23 AM, Christian PERRIER  wrote:
> Quoting Josselin Mouette (j...@debian.org):
>
>> I fully support this, and I’d like indeed to remove some more obsolete
>> libraries for wheezy. We should start with HAL and gnome-vfs, which are
>> big things. Along the way I’d like to get rid of the least used GTK2
>> libraries in favor of their GTK3 counterpart.
>
> How about dropping defoma ?
>
> The pkg-fonts team did that on fonts we maintain, but there are many
> other fonts packages (some of them somehow abandoned or loosely
> maintained) that need to do it.

If anyone wants to help there, more info here:

http://wiki.debian.org/OldPkgRemovals#defoma

Main blockers are Xorg, ghostscript and the other remaining backends
(libwmf, vflib3).

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
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/aanlktinfvh-hbfdwdrcppkbyws53mcjuu0awowlyf...@mail.gmail.com

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

2011-03-30 Thread Javier Fernández-Sanguino Peña 
On Fri, Mar 11, 2011 at 12:11:40AM +0100, Adam Borowski wrote:
> > > > Package: netselect-apt
> > > > Description: speed tester for choosing a fast Debian mirror
> 
> Does it actually work for anyone?  I just tried it from machines at four
> different locations on 3½ ISPs; two with IPv6+IPv4, two IPv4 only; two with
> no NAT; all with full UDP/ICMP connectivity -- getting an empty result every
> single time (#23, #582976).

From my experience, netselect-apt failed to work if UDP probes are blocked.
Since version  0.3.ds1-15 in unstable netselect-apt uses ICMP probes only as
most Debian mirrors do not have full UDP connectivity (i.e. UDP probes
are blocked).

> 
> netselect-apt somehow requires root, I got none on a machine outside of
> northern Poland so I can't test if it's something caused by a specific
> mirror.

netselect-apt requires root because netselect requires it for its UDP (or
ICMP) probes. It is documented in its README.Debian file.
If you have not installed netselect setuid root this it what
will happen:

$ netselect-apt sid
Sorry, you need to be root to run /usr/bin/netselect-apt since the netselect
binary we will use (/usr/bin/netselect) is not setuid.


Regards

Javier


signature.asc
Description: Digital signature

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Yaroslav Halchenko 

On Wed, 30 Mar 2011, Michael Tautschnig wrote:
> > # package quality
> >   Advocate: Holger Levsen and Luk Claes
> >   State: confirmed
> >   Wiki: http://wiki.debian.org/ReleaseGoals/PackagesQuality
> > This is a never ending goal of sustaining our packages quality by
> > improving our tests and following up closely... so needless to say that
> > I would still advocate this one.
> I would advocate the idea behind this goal as well, yet I think as-is this 
> isn't
> a very useful goal: how would we ever measure its achievement? To this end, I

guarantee build-time run of unittests if such are provided  by upstream.

in my experience those were really helpful, especially for exotic
architectures.

side-question:  what to do about source packages shipping only binary
 packages of arch 'all' (thus not rebuilt by the farm) while still
 susceptible to architectures specificity.

-- 
=--=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic


-- 
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/20110330233503.gh6...@onerussian.com

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Henrique de Moraes Holschuh 
On Thu, 31 Mar 2011, Goswin von Brederlow wrote:
> > /etc/adjtime

This needs to survive reboots, and it is also needed early in the boot.
It is used to correct the RTC syndrome.

I am at a loss about how it could be made compatible with RO /.

> > /etc/hosts.deny (written by denyhosts, hence that one is a bit hard to fix)
> 
> Don't have that. Fix denyhosts to link that to /var/ (or /run when we
> have it).

Has to be available before any tcp-wrapped network service is started.

-- 
  "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/20110330234806.ga22...@khazad-dum.debian.net

Re: throw away debs and source only uploads

2011-03-30 Thread Charles Plessy 
Le Wed, Mar 30, 2011 at 04:18:34PM +0200, Stefano Zacchiroli a écrit :
> 
> Regarding source only upload, well, it's tricky. There is the usual
> tension about the principle desire of trusting every DD to do the right
> thing and the reality-check observation that enabling people to upload
> only sources *will* mean that some people will upload packages without
> having even built them once

Hi Stefano,

I think that one important factor is how often such errors will happen.  We can
imagine all sorts of scenarios and devise counter-mesures against them, but are
they all worth the effort, and worth the damage as well ?  Because it is always
frustrating to read top-down comments about simple Debian developers to be
sloppy and untrustable.  Let's not make it a common assumption.

In what I have seen in the packaging teams that I follow, often when a package
fails to build on all architectures, it is because the developer has not tested
them in a minimal build environment.  Making sure that binary packages have been
built together with the source package is not solving that problem.

On the binary side as well, what the maintainer can do to test the packages by
hand is also limited, not to mention that testing more than one architecture is
time consuming (so I usually never do).  Build-time regression tests and
facilities to let users run the same tests on the binary packages they
downloaded (DEP8 ?) will altogether do much more for the quality of Debian than
using the presence of binary packages accompaniying the source upload as an
evidence of significant qualitative difference compared to a source-only upload.

Asking developers to publish their build logs is far more interesting, and in
the short term, does not require any infrastructure change.  Currently, I store
my build logs in the git repositories where my source packages are managed, and
in the case of subversion packages, I send the logs on the maintainer mailing
list.  If the uploaded package turns out to be problematic, we have a starting
point for troubleshooting.

And when developers repeatedly commit the same mistake, refuse to realise the
damage they do, and persist in ignoring the solution to the problems they
cause, let'se withdraw the trust we gave them.  But does that happen that
often ?  My experience is that people learn and improve their skills, not the
reverse.  In that sense, occasional failures to build, while not a goal by
themselves, are an inevitable byproduct of increasing our workforce.  Automated
reporting of build failures can circumvent the nuisance to the package
maintainers themselves.

Cheers,

-- 
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/20110331001718.ga...@merveille.plessy.net

Bug#620202: ITP: lcrt -- Linux remote login tool

2011-03-30 Thread Asias He 
Package: wnpp
Severity: wishlist
Owner: Asias He 


* Package name: lcrt
  Version : 1.0.0
  Upstream Author : NiuTao 
* URL : http://code.google.com/lcrt
* License : GPL2
  Programming Lang: C
  Description : Linux remote login tool

Lcrt is a Linux Remote Login Tool. Some linuxer think there is not
a good terminal like SecureCRT(may be there is but I don't known), 
so I write one, here it is.



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

Re: Bits from the Release Team - Kicking off Wheezy

2011-03-30 Thread Reinhard Tartler 
On Wed, Mar 30, 2011 at 19:51:17 (CEST), Michael Biebl wrote:

> HAL removal is already in progress, see [1]. Actually I've been working on 
> that
> for some time already. I wouldn't object obviously making that a release goal.

How well does kFreeBSD cope with HAL gone missing? AFAIUI udev isn't
available there. 

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


-- 
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/87bp0rx3kw@faui44a.informatik.uni-erlangen.de

Re: Bug#620202: ITP: lcrt -- Linux remote login tool

2011-03-30 Thread Andrei Popescu 
On Jo, 31 mar 11, 08:58:27, Asias He wrote:
> 
> Lcrt is a Linux Remote Login Tool. Some linuxer think there is not
> a good terminal like SecureCRT(may be there is but I don't known), 
> so I write one, here it is.

apt-cache show putty

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature