date:20130509

On 05/07/2013 10:34 PM, Paul Wise wrote:
> On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote:
>
>> Debian backports offers me *one* repository. I need 3 of them:
> I don't see why. The combination of suites we have now should be
> enough. Here is what I would do...
>
>> - stable -1 (currently OpenStack Folsom)
> Ignore, is there any reason why an old version is interesting?
It's currently not possible to upgrade from Essex (which is
in Wheezy) to Grizzly (which is currently in Experimental).
You need to upgrade through Folsom first. At least, that
is the current upstream status, I'll have to find a solution.

>> - stable (currently OpenStack Grizzly)
> sid+jessie+wheezy-backports+squeeze-backports-sloppy

Well, I'd like to run a backport for Wheezy only, I don't
want to have it in sid+jessie. Currently, I can't do that.

>> Also, the rules in backports is that packages should be already migrated
>> to testing. The point is, if I had PPAs, I wouldn't at all upload to SID
>> and wait
>> for a migration to testing, because it would be better if the packages were
>> living in the PPA only (that would be a lot more flexible and adapted to my
>> use case).
> I think that would be a bit sad and I hope you don't do that.
I agree. I tried to explain that to upstream, but no luck so far...
There's not much I can do, especially with a project of that size.

Distributions like Ubuntu and Debian have the same pb though.
Probably RedHat too.

Thomas


-- 
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/518b570a.4080...@debian.org

Re: jessie release goals

2013-05-09 Thread Mike Hommey

On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> Hi,
> 
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
> 
> * multiarch compatible binNMUs
> * discarding maintainer uploaded binary packages [!arch:all]
> * discarding maintainer uploaded binary packages [incl. arch:all]
> * extending binNMUs to allow rebuilding arch:all packages (so it's no
> longer a "binary only" but a sourceful no-change rebuild - the classic
> binNMU should stay of course)

* source build dependencies (such that e.g binutils-mingw-w64 build
  depends on src:binutils instead of binutils-source)

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/20130509081001.ga13...@glandium.org

Re: Merging / and /usr (was: jessie release goals)

On Thu, 9 May 2013 03:31:30 +0200, m...@linux.it (Marco d'Itri) wrote:
>This is not relevant for what we are talking about because /usr *will* 
>be required be available to boot the system no matter where the files 
>currently in /{bin,sbin,lib} will end up.

Yes. That is really bad news and I hate the idea to be forced to do
things just because a few developers are too lazy to care about
robustness. But I also acknowledge that Debian does not have the
personpower to fix upstream's deliberate breakage.

>If your goal is to have the smallest and least accessed file system 
>available for recovery then I recommend that you create a 200-250 MB 
>/boot and install grml-rescueboot.

That's how I do it for new installs. However, this is vastly more
complex than the traditional setup, and it doesn't help for systems in
maintenance mode that, for example, cannot be changed because of
service level agreements and certifications.

Using Debian happens beyond single-user home desktop settings, you
know.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

--
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/e1uamgn-0002ad...@swivel.zugschlus.de

Re: Merging / and /usr (was: jessie release goals)

On Thu, 9 May 2013 03:43:44 +0200, m...@linux.it (Marco d'Itri) wrote:
>Let's assume that at this point there are no files in /{bin,sbin,lib} 
>which have the same name of a file in /usr/{bin,sbin,lib} but are not 
>a symlink to them (which I suspect is something that we want anyway).
>
>For each $file in /{bin,sbin,lib}:
>  if $file is a symlink to /usr/.../$file
>do nothing
>  else
>cp -a $file to /usr/...
>ln -sf ../usr/.../$file $file

That's a hack which is acceptable for single-user home desktops. We're
talking about professional IT here.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1uamhk-0002ar...@swivel.zugschlus.de

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Marco d'Itri

On May 09, Marc Haber  wrote:

> That's a hack which is acceptable for single-user home desktops. We're
> talking about professional IT here.
Great, if this is the strongest objection you have then looks like it 
can be done.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: jessie release goals

2013-05-09 Thread Stephen Kitt

On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey  wrote:
> On Mon, May 06, 2013 at 02:49:57PM +0200, Andreas Beckmann wrote:
> > Hi,
> > 
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
> > some were already discussed very recently):
> > 
> > * multiarch compatible binNMUs
> > * discarding maintainer uploaded binary packages [!arch:all]
> > * discarding maintainer uploaded binary packages [incl. arch:all]
> > * extending binNMUs to allow rebuilding arch:all packages (so it's no
> > longer a "binary only" but a sourceful no-change rebuild - the classic
> > binNMU should stay of course)
> 
> * source build dependencies (such that e.g binutils-mingw-w64 build
>   depends on src:binutils instead of binutils-source)

Yes! That was on my list as well ;-). The Built-Using stanza could even be
filled in automatically in such cases...

Stephen


signature.asc
Description: PGP signature

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Helmut Grohne

On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
> It is good to have it released now, but I think we are all (mostly?)
> agreed that wheezy took longer to release than we would have liked.
> In particular, the RC bug count didn't drop "quickly enough".

Thanks for bringing this up!

I would like to take this opportunity to post an experience report and
give some conclusions I'd make from that.

During the wheezy cycle I participated in the 2011 Hildesheim BSP. In my
experience BSPs are among the best places to get difficult issues sorted
out. Political issues tend to play less of a role there and it
participants tend to motivate each other not to give up on technical
challenges. I would like to thank all the BSP organizers for their
valuable contributions to the project.

During said BSP I settled on fixing #88010 (yes five digits, policy
violation, {lenny,squeeze}-ignore). It clearly meets the criterion of
"hard" and fixing it took more than a year. Here are a few observations
on the process:

 * The largest amount of time used for fixing went into communication.
   Sometimes I would wait for multiple months to receive an essential
   answer from involved parties. This had a multitude of reasons and I
   would like to avoid a blame game here, but this ultimately resulted
   in missing the freeze and later resulted in last-minute changes.

 * There were a great many people who helped me with technical aspects,
   that were sufficiently isolated and did not require a broad view on
   the issue. This applies especially to the changes in packaging, the
   involved perl code, the usage of dpkg triggers and the transition
   tool set.

 * Even though I had a variety of people review the changes introduced,
   the first attempts resulted in a variety of new failure modes.

   Remark: The PPA thingy might be part of the solution here. As it
   would make testing transitions easier.

>  * Try to think of workflows which might overcome these problems

Given the experience above and the experience with other RC bugs, I
would like to suggest to form semi-spontaneous teams around some RC
bugs. The rationale here being is that some "hard" RC bugs tend to be
quite complex and complexity made me give up on other issues. We already
have the notion of "owner" in the BTS, but its usage appears to be
limited (and I didn't use it either for RC bugs so far). By forming a
team around a particular issue, we can contain the complexity and
motivate each other. This is not to say that such a team is to do the
full fix, but to give a direction and coordinate the involved parties.
The team would be tasked with avoiding stalls in the progress, pinging
and possibly timing out involved parties. Possibly writing regular
progress summaries would also be helpful to evaluate the performance of
the team. Such summaries would also make switching the owner later
easier. This model should also work with single person teams, but I'd
fear that a single person could more easily run into political
acceptance issues.

This is just a rough sketch so far, and I cannot tell whether it
actually works. Rereading the above paragraph, it sounds a bit like
"mini release goal".

Helmut

-- 
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/20130509090056.ga28...@alf.mars

Call for help: archive rebuilds

2013-05-09 Thread Lucas Nussbaum

Hi,

I'm unlikely to be able to do much archive rebuild work in the coming year, so 
I would welcome help on that front.

Here is the "job" description:
- maintain scripts to organize archive rebuilds, parse logs and file bugs
  Required skills: basic Ruby knowledge (or willingness to learn)
  scripts are in
  http://anonscm.debian.org/gitweb/?p=collab-qa/cloud-scripts.git
  and
  http://anonscm.debian.org/viewvc/collab-qa/collab-qa-tools/

- do the archive rebuilds themselves on Amazon Web Services
  Required skills: basic AWS knowledge (or willingness to learn)

- process results and file bugs (there are scripts that allow to automate
  most of the process).
  Required skills: good understanding of FTBFS bugs (common causes for 
  failure, etc), and of the BTS

- answer to questions from maintainers

Overall, one important "skill" is the ability to dedicate time to this task on 
a regular basis (on average, approx. 3 hours every 3 weeks).

The task covers "normal" archive rebuilds (rebuilding all packages, including 
source and arch:all, from source), but also custom rebuilds (new 
GCC/python/eglibc/... releases, clang), and possibly QA-specific targets 
(double-builds, non-minimal chroots, etc.)

It is not required to be a DD or DM.

Please reply to debian...@lists.debian.org if you are interested.

Lucas


-- 
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/20130509093205.ga16...@xanadu.blop.info

Re: Depends: libfoo:foreign ???

2013-05-09 Thread Goswin von Brederlow

On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote:
> On 2013-05-09 07:56, Paul Wise wrote:
> > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
> > 
> >> I just noticed that we have the first amd64 package in the archive that
> >> has dependencies on :i386 qualified libraries:
> >>
> >> Package: teamspeak-client
> > 
> > It appears that will block it from reaching testing:
> > 
> 
> Indeed, Britney does not support those annotations (at the moment?).  To
> avoid issues with this kind of thing, we made her consider such
> dependencies for unsatisfiable[1].
>   So for now anything using that form in Depends or Pre-Depends will not
> reach testing (without manual intervention from the Release team and I
> am not sure how likely "we" are to do that).
> 
> > http://packages.qa.debian.org/t/teamspeak-client.html
> > 
> > The proper thing to do would be to remove the amd64 package entirely
> > and have users install the i386 version.
> > 
> 
> Indeed, I believe that should work.

It is the indended solution. If it doesn't work then that is a bug and
needs to be fixed.

> ~Niels
> 
> [1] Though she ignores them in Recommends/Suggests and possibly also in
> Breaks/Conflicts.

A Depends like in this case is never right since it mixes biarch
(libc6-i386) packages with multiarch (libfoo:i386).

I would say that a foreign dependency on a library is never right. If
the source compiles binaries for the foreign arch then the package
should be build on the foreign arch directly. Period.

Also, iirc, the use of foreign dependencies is only supposed to be on
packages with Multi-Arch: allowed. This is for interpreters and
plugins/lib bindings where the normal automatic method can't work. So
maybe DAK could be made more restrictive here.

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/20130509093918.GA31432@frosties

Re: epoch fix?

2013-05-09 Thread Philip Hands

Thomas Goirand  writes:

> On 05/08/2013 06:30 PM, Peter Samuelson wrote:
>> # in unstable
>> Package: bar
>> Build-Depends: libfoo-dev (>= 1.5)
>>
>> The 'bar' maintainer intended to require the unstable version of
>> libfoo-dev, but in fact the dependency is satisfied from stable as
>> well.
> Yeah! And this mistake is very easy to make.
>
> I did a similar "woopsie" recently myself with Breaks / Replaces,
> (which was quickly solved) even though I quite know what
> I was doing, simply because I forgot about the epoch. Of course,
> that made the Breaks / Replaces completely useless.
>
> Though, is there a way to fix human brains? I don't think so...
> Would having the epoch written in the generated file names
> solve the problem? I don't think so either...

Looks like it might be possible to for test with lintian.

I presume it's OK to add the implicit 0: to non-epoch depends?

If so, lintian could complain whenever a dependency is specified on a
package with an epoch, unless the versions specified also include an
epoch, and if you really meant the pre-epoch version, you could just add
the 0: to get rid of the warning.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpdxqX7u2zkk.pgp
Description: PGP signature

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Goswin von Brederlow

On Tue, May 07, 2013 at 04:56:04PM +0100, Roger Leigh wrote:
> On Tue, May 07, 2013 at 05:35:11PM +0200, Marco d'Itri wrote:
> > On May 07, ?? ??  wrote:
> > 
> > > What about merging / and /usr ?
> > An ambitious plan.
> > I strongly support the "everything in /usr" scheme, but let's first 
> > consolidate support for "standalone /usr must be mounted by the 
> > initramfs".
> 
> I'm working on this at the present (I'm re-doing the proof of concept
> patches I made a few months back, to clean it all up and make it work
> in a wider number of cases).  I hope to have something by the end of
> the week, time permitting.
> 
> That said, I'm not in support of moving things to /usr; it's completely
> backward.  Once we have / and /usr mounted in the initramfs, then we
> can work on deduplicating shared paths on / and /usr.  This will give
> us the option of migrating either way in the future (if ever).  If we
> do this, I'd prefer to make /usr a symlink to / on new installs, while
> retaining full backward compatibility for existing users, and requiring
> zero packaging changes.  But the other way would also be possible--it
> would just be a matter of d-i setting up the links.  But none of this is
> the primary reason for doing this initially.
> 
> 
> Regards,
> Roger

If you make /usr a symlink to / then there will be to distinct paths
to each file and that will confuse dpkg.

The first problem that comes to mind is package A containing /bin/foo
and package B containing /usr/bin/foo. Dpkg will happily install both
without noticing the file overwrite conflict.

Or package A 1.0 contains /bin/foo and package A 1.1 contains
/usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo
with /usr/bin/foo) and then remove /bin/foo. Leaving you without
/usr/bin/foo.

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/20130509095031.GB31432@frosties

Re: DPA instead of PPA

On 05/09/2013 02:38 PM, Raphael Hertzog wrote:
> Hi,
>
> On Wed, 08 May 2013, Holger Levsen wrote:
>> I actually really like this idea! (Though I suggest "Debian Personal 
>> Archive".)
>>
>> It's really different from what people know as PPAs.
> To be fair, "Personal" is probably not relevant either. I expect many of
> those repositories to be maintained by teams.
>
> DSPA = Debian Special Purpose Archive
> DSPR = Debian Special Purpose Repository
> DASP = Debian Archive of Special Packages
> SPA = Special Package Archive
>
> bikeshed \o/
Seriously, any of the above would be better than PPA.
Naming it like for Ubuntu fools our users into believing
it is the same thing, when the plan is not like that.

I like the first name above.

Thomas


-- 
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/518b7469.2090...@debian.org

Re: Doubts about PPA in Debian

On 05/07/2013 04:12 PM, Tollef Fog Heen wrote:
> Providing backports doesn't free you from the burden of making sure
> upgrades work.  Thomas is facing a very large chunk of work to make sure
> upgrades from the no-longer-supported E release to whatever might be in
> jessie, since upstream breaks APIs and doesn't support skipping releases
> when upgrading.

Yeah, you got the point. Though what breaks is mainly db
upgrades (using python-migrate, I'll have to care about
adding previous scripts, etc.).

Thomas


-- 
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/518b7509.3000...@debian.org

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Goswin von Brederlow

On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote:
> On 05/07/2013 11:41 AM, Paul Tagliamonte wrote:
> 
> >On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote:
> >
> >>On May 07, Paul Tagliamonte  wrote:
> >>
> >>>No please. We are good about making sure they each mean something
> >>>important, and there's no good reason.
> >>
> >>Not really nowadays: more and more things needed at boot time are
> >>in /usr and there are no plans to "fix" them.
> >>
> >>>We also support setups that might need this split due to low
> >>>storage, such as arm devices.
> >>
> >>"everything in /usr" actually means that supporting these devices
> >>is much easier.
> >
> >Not when you have a 500 meg internal storage that the firmware boots
> >off of, and using a multi-gig CF card to store the mega-awesome-app
> >you're using it for.
> 
> This seems to point to what I think may be a key question in the
> ongoing/recurring '/usr'-related discussions, which I don't think I've
> seen addressed in the iterations I've seen. If it has been addressed
> well, please point me to past iterations which have so addressed it,
> rather than rehashing the whole thing here just for my benefit.
> 
> The question, expressed in a number of different ways to provide a type
> of "clarity by triangulation", is: Why does /usr exist in the first
> place? Why was it created, way back in the day? What is its purpose,
> what is it for?
> 
> 
> My understanding, to the extent that I've had one, has always been that -
> to oversimplify it a bit - / is for installs of things which are
> system-essential, and /usr is for installs of things which are not. The
> definition of "system-essential" can be debated, but again, my
> understanding of it has been that it incorporates A: "boot-essential"
> (things required for boot) plus B: "emergency tools" (things you want to
> try to guarantee will be available in an emergency,
> things-are-broken-and-we-have-to-fix-them scenario, such as might leave
> you needing to rely on single-user mode).

The initial problem was that the harddisk was too small. So you had to
split things up into 2 harddisks somewhere. / was the first disk, /usr
the second. We have long since past this problem.

Except it is comming back. With embedded systems that boot from a
"small" flash that contains / and then have /usr on a non-bootable
drive.

But those systems can put an initrd on flash to boot. I'm not aware of
any situation where an initrd can't be used (can't, not don't want to).

For Debian the problem has become that / must contain everything
needed to be able to mount /usr. And that includes such odd cases as
/usr on NFS over wlan and a million other permutations of any possible
way to hide /usr somewhere.

The problem in recent years has been twofold:

1) some people have become more creative and used new things to put /usr
on. Like iscsi or nfs over wlan. So more tools are needed in / to make
this possible.

2) most people don't have a seperate /usr or /usr on the same medium
as / and upstreams have been ignorant or neglient about ensuring the
right things end up in / and only things from / are used before
mounting /usr. The less people have a seperate (and complicated) /usr
the less this is tested and more bit-rot creaps in.

We have reached a point where other distributions have given up and
upstreams are saying they don't care for a seperate /usr anymore.

> The real-world scenario is obviously far more complicated than that -
> dragging in definitions for what goes in /etc and /var and /home, and
> further defining a distinction between /usr and /usr/local, and so
> forth. But the basic concept seems simple enough as far as it goes.
> 
> 
> Now, the next question is: does that distinction, that defining purpose
> for the existence of /usr, still make sense in the modern world?
> 
> Almost everyone boots via an initrd nowadays AFAIK, which would seem to
> more or less negate the advantages of keeping boot-essential things
> separate that way - but "almost" still isn't everyone, and I don't know
> whether we want to explicitly step away from support for non-initrd boot
> configurations.
> 
> The "emergency tools" side of it I'm less clear on. It's relatively
> unimportant for cases where you have physical access to the system in
> the emergency scenario, assuming you can take the machine down long
> enough to boot into a rescue environment on removable storage (LiveCD or
> USB drive, et cetera), but there may not be any analogous alternate
> fallback for cases where you only have remote access to a machine, or
> where taking the machine down that way may not be an option. There's
> also the question of what scenarios this could actually help in, which
> may be limited enough to make the entire thing negligible.

On most (numerically) systems you have a bootloader that lets you
choose what to boot and it is trivial to add an emergency initrd with
all the repair tools you would ever want.

That is actualy much b

Re: DPA instead of PPA

2013-05-09 Thread Simon McVittie

On 09/05/13 07:38, Raphael Hertzog wrote:
> bikeshed \o/

You probably meant this to be a comment on the discussion rather than a
suggested name, but "until it gets uploaded to unstable, you can get
GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a
reasonable sentence to write. :-)

(Or more seriously, maybe (mini|sub)-(archive|repository), to have
slightly fewer acronyms floating around.)

S


-- 
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/518b7cf6.3080...@debian.org

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Roger Leigh

On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote:
> If you make /usr a symlink to / then there will be to distinct paths
> to each file and that will confuse dpkg.
> 
> The first problem that comes to mind is package A containing /bin/foo
> and package B containing /usr/bin/foo. Dpkg will happily install both
> without noticing the file overwrite conflict.
> 
> Or package A 1.0 contains /bin/foo and package A 1.1 contains
> /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo
> with /usr/bin/foo) and then remove /bin/foo. Leaving you without
> /usr/bin/foo.

This is all very true.  Once we have /usr mounted in the initramfs,
we can correct such duplicate paths to prevent this; packages which
provide a binary in /bin and a symlink in /usr/bin to make the binary
available in early boot can simply move the binary back to /usr--it
will be guaranteed to be available in early boot.  Since two different
paths would then be effectively equivalent, maybe we might also need
dpkg itself to be aware of this so that it will refuse to overwrite,
in addition to a manual audit of the existing paths.

My current work on this is at
http://anonscm.debian.org/gitweb/?p=users/rleigh/initramfs-tools.git;a=shortlog;h=refs/heads/usrmount
It works for mounting a local /usr; testing NFS and NFS/local
combinations is on my TODO list for tonight.  This still needs further
cleanup and testing.  It will be ready for wider testing in a few days.
It also needs a patch to util-linux so it doesn't try to fsck a mounted
/usr at boot.

Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

-- 
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/20130509110342.gq21...@codelibre.net

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Lucas Nussbaum

On 09/05/13 at 08:32 +0200, Niels Thykier wrote:
>   The execution of the time-based freeze might have failed.  Also,
> "testing" did not serving its purpose of "always being in (a
> near-)releasable state"[2] with its 500+ RC bugs at the start of the
> freeze was not ideal (either?).

I think that one problem is that our current workflows are based on the
illusion that all RC bugs are equal.

Our tools (e.g. http://udd.debian.org/bugs.cgi) should get better at
differenciating different kinds of RC bugs. For example:
- old RC bugs vs new RC bugs: experienced bug squashers should focus on
  the old RC bugs, not on the maybe-trivial-to-fix new RC bugs.
- RC bugs affecting popular/important packages vs RC bugs affecting
  minor packages (that we could remove without).
We should include such distinctions in the various graphs we use to
track progress.

Also, we should be more agressive at getting down the number of RC bugs
by automatically removing RC-buggy not-so-important packages. For
example, if we keep the current time-based freeze policy for jessie, we
could announce that all not-so-important RC-buggy packages will be
removed from testing on freeze date.

Lucas

-- 
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/20130509105503.ga21...@xanadu.blop.info

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Christoph Egger

Hi!

Lucas Nussbaum  writes:
> Also, we should be more agressive at getting down the number of RC bugs
> by automatically removing RC-buggy not-so-important packages. For
> example, if we keep the current time-based freeze policy for jessie, we
> could announce that all not-so-important RC-buggy packages will be
> removed from testing on freeze date.

  I'm not so persuaded this will actually improve anything. During lenny
freeze I've fixed a couple of these easy RC bugs on unmaintained leave
packages when I had some 30 minutes of time and no good Idea of what to
do. I have had similar timeslots too small to actually get into more
difficult RC bugs but couldn't find anything to do during squeeze and
especially wheezy freeze so I ended up doing *nothing*.

  Removing RC-buggy (and potentially not-taken-care-of) packages early
may increase the average quality of software in the release (because
these fixes mostly do exactly as much as is needed to fix the RC bug)
but I'm far from persuaded it will increase release speed. Different
thing for will-remove and dropping such packages late of course.

Christoph

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

-- 
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/8761ysbe09@hepworth.siccegge.de

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Julien Cristau

On Thu, May  9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote:

> Also, we should be more agressive at getting down the number of RC bugs
> by automatically removing RC-buggy not-so-important packages. For
> example, if we keep the current time-based freeze policy for jessie, we
> could announce that all not-so-important RC-buggy packages will be
> removed from testing on freeze date.
> 
define:not-so-important.  I'm sure that'll be fun.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: DPA instead of PPA

2013-05-09 Thread Andreas Beckmann

Another opportunity these XPAs will bring, especially the ones that will
be used for staging large transitions, is to run piuparts and related
tests to discover (and fix) problems before they get introduced into
unstable.


Andreas


-- 
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/518b827b.9080...@debian.org

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Timo Juhani Lindfors

Lucas Nussbaum  writes:
> Also, we should be more agressive at getting down the number of RC bugs
> by automatically removing RC-buggy not-so-important packages.

This sounds like a good idea. If somebody is interested in the package
they can easily reintroduce it after they have fixed the bug.


-- 
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/84fvxwpez8@sauna.l.org

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Roger Leigh

On Wed, May 08, 2013 at 08:14:32PM +0200, Marc Haber wrote:
> On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne 
> wrote:
> >On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
> >> Fedora updates are different. (And so are Ubuntu updates, if one considers
> >> that it's possible to provide fixup scripts to update-manager pre-upgrade.)
> >> As long as we're supporting upgrades through plain apt, that's going to
> >> be hard. Especially if you have non-distro packages installed that need
> >> to be migrated as well, with the tracking information updated.
> >
> >Maybe the issue here shouldn't be changing the default. After all there
> >is a quite vocal opposition to such a step. I fail to see consensus in
> >the recent mails without even contributing a personal opinion here.
> >
> >So really what does it take to e.g. move /bin and stuff to /usr? Did
> >anyone try that? Where is that documented? What problems did occur?
> 
> If we force a much bigger /, the chance of a broken / filesystem
> increases.  If / is fine, one has a chance to fix the system without
> booting to rescue. So, a small / both decreases the probability of a
> boot failure and makes fixing breakage easier.

The assumptions here are that a separate rootfs decreases the chance
of breakage, and that you'll need the rootfs to perform the rescue.

Does having two filesystems rather than one decrease the chances, or
increase them?  Neither are written to much during normal system
operation, and they can both be mounted read-only.  Do we have any
concrete evidence one way or the other here?

Regarding rescue, the initramfs has a rescue shell which I've found
to be just as useful as single user mode.  Once it has mounted the
rootfs, you can chroot into that and do whatever you would normally
do to rescue /usr. [Assuming a separate /usr.]  If it doesn't get as
far as mounting the rootfs, then you'll need some rescue disc in any
case.  I find the busybox shell to be just as effective as a rescue
disc in most cases.

In the case where we're mounting /usr in the initramfs rather than
having it on the rootfs, there's no practical difference to the
current status quo (and this is intentional).  The only change is
that we provide the guarantee that /usr is available before init
starts.

> If we change our software so that the system never gets beyond initrd
> stage if mount /usr fails, we increase the change of breaking boot
> because _two_ filesystems need to be fine and mounted before we leave
> initrd.
> 
> Both changes are bad from a robustness point of view. Keeping the root
> fs small was a good idea 20 years ago, and it still is.

I think this is primarily just shifting the lines of where
responsibilities are divided.  The initramfs is doing part of the job
of what the separate rootfs was doing.  If there's a problem, then you
get the rescue shell in the initramfs rather than the rescue shell from
the initscripts/single user mode.  In all these cases, the system is
unavailable for normal operations until the problem is fixed.

There was some mention of putting fsck in the initramfs.  I'm not
sure whether I really like the idea or not, but from the point of
view of having the tools to fix and mount the rootfs (and /usr) there
when needed, it may well be useful, so long as we can avoid idiocy
such as #701936.  We still need the fsck helpers to work for the
non-initramfs case and also not be utterly broken.

Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800

-- 
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/20130509113347.gr21...@codelibre.net

Bug#707554: ITP: hyphen-ru -- Russian hyphenation patterns for LibreOffice/OpenOffice.org

2013-05-09 Thread Ильяс Гасанов

Package: wnpp
Severity: wishlist
Owner: Ilyas Gasanov 

* Package name: hyphen-ru
  Version : 20030310
  Upstream Author : Alexander I. Lebedev 
* URL : http://scon155.phys.msu.su/~swan/hyphenation.html‎
* License : LPPL
  Programming Lang: none
  Description : Russian hyphenation patterns for LibreOffice

I have patched Alexander Lebedev's hyphenation patterns (ruhyphal)
already found in the texlive-lang-cyrillic Debian package and the
ruhyphen CTAN package, so that they would work with LibreOffice. The
reason why I have chosen exactly these patterns is because, among those
released under a free license, they seem to give the best orphographical
results while their format is generally supported by LibreOffice.

These patterns have been released by the author under the terms of the
LaTeX project public license version 1.2 (with an option of choosing any
later version), thus I see no problems for my package to formally fit
the DFSG and be included into the main distribution branch.

Since I am not a Debian Developer yet, I'm uploading the complete
package to the mentors.debian.net storage for sponsorship approval.

Best regards,

Ilyas


-- 
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/1368099204.5831.31.camel@lamed

can someone explain what is happen on line one from this listing?

2013-05-09 Thread Mailbox


Hello Developer Group,

can someone explain what is happen on line one from this listing?

why i loos the interrupt?

what is the Status 0x50?

has someone a idea in which Documentation an can finde more informations 
about 0x50?


May  7 19:39:57 lxhs110a kernel: [316946.812055] ata2: lost interrupt 
(Status 0x50)
May  7 19:39:57 lxhs110a kernel: [316946.812072] ata2: exception Emask 
0x10 SAct 0x0 SErr 0x4405 action 0xf
May  7 19:39:57 lxhs110a kernel: [316946.812116] ata2: SError: { 
PHYRdyChg CommWake DevExch }

May  7 19:39:57 lxhs110a kernel: [316946.812156] ata2: hard resetting link
May  7 19:39:58 lxhs110a kernel: [316947.536038] ata2: SATA link up 1.5 
Gbps (SStatus 113 SControl 300)
May  7 19:39:58 lxhs110a kernel: [316947.560823] ata2.00: configured for 
UDMA/133
May  7 19:39:58 lxhs110a kernel: [316947.560831] end_request: I/O error, 
dev sdb, sector 25141733
May  7 19:39:58 lxhs110a kernel: [316947.560876] md: super_written gets 
error=-5, uptodate=0
May  7 19:39:58 lxhs110a kernel: [316947.560880] raid1: Disk failure on 
sdb4, disabling device.
May  7 19:39:58 lxhs110a kernel: [316947.560881] raid1: Operation 
continuing on 1 devices.

May  7 19:39:58 lxhs110a kernel: [316947.560962] ata2: EH complete
May  7 19:39:58 lxhs110a kernel: [316947.595196] RAID1 conf printout:
May  7 19:39:58 lxhs110a kernel: [316947.595198]  --- wd:1 rd:2
May  7 19:39:58 lxhs110a kernel: [316947.595201]  disk 0, wo:1, o:0, 
dev:sdb4
May  7 19:39:58 lxhs110a kernel: [316947.595203]  disk 1, wo:0, o:1, 
dev:sda4

May  7 19:39:58 lxhs110a kernel: [316947.608009] RAID1 conf printout:
May  7 19:39:58 lxhs110a kernel: [316947.608011]  --- wd:1 rd:2
May  7 19:39:58 lxhs110a kernel: [316947.608013]  disk 1, wo:0, o:1, 
dev:sda4


thanks
Paulo


--
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/518b8c73.20...@ai-t.eu

Bug#707556: ITP: node-keypress -- Make any Node ReadableStream emit "keypress" events

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-keypress
  Version : 0.1.0
  Upstream Author : Nathan Rajlich 
* URL : https://github.com/TooTallNate/keypress
* License : MIT
  Programming Lang: Javascript
  Description : Make any Node ReadableStream emit "keypress" events

 Previous to Node v0.8.x, there was an undocumented "keypress" event that
 process.stdin would emit when it was a TTY. Some people discovered this
 hidden gem, and started using it in their own code.
 .
 In Node v0.8.x (and above), this "keypress" event does not get emitted by 
default,
 but rather only when it is being used in conjuction with the readline (or
 by extension, the repl) module.
 .
 This module is the exact logic from the node pre-v0.8.x releases ripped out
 into its own module.
 .
 Bonus: Now with mouse support!


-- 
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/20130509115914.480.41796.report...@minobo.das-netzwerkteam.de

Re: Merging / and /usr (was: jessie release goals)

On Thu, 9 May 2013 12:33:47 +0100, Roger Leigh 
wrote:
>Regarding rescue, the initramfs has a rescue shell which I've found
>to be just as useful as single user mode.

Isn't that the one that doesn't even have a shell history or tab
completion?

>Once it has mounted the
>rootfs, you can chroot into that and do whatever you would normally
>do to rescue /usr. [Assuming a separate /usr.]  If it doesn't get as
>far as mounting the rootfs, then you'll need some rescue disc in any
>case.

You have a point here. The problem is that people need to change their
operations, which is hard for many people, let alone the case when
emergency manuals need to be changed just for the sake of satisfying
Lennart.

>I find the busybox shell to be just as effective as a rescue
>disc in most cases.

I don't.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1uapdl-00061q...@swivel.zugschlus.de

Re: Merging / and /usr (was: jessie release goals)

On Thu, 9 May 2013 10:40:14 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 09, Marc Haber  wrote:
>> That's a hack which is acceptable for single-user home desktops. We're
>> talking about professional IT here.
>Great, if this is the strongest objection you have then looks like it 
>can be done.

If you don't care about the companies that use Debian and you want
their sponsoring money to go elsewhere, yes, absolutely do this.

Otoh, companies runnign IT shops are used to being screwed, so Debian
screwing them will be an experience they're already used to.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1uapez-000620...@swivel.zugschlus.de

Bug#707559: ITP: node-commander -- The complete solution for Node.js command-line interfaces

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-commander
  Version : 1.1.1
  Upstream Author : TJ Holowaychuk 
* URL : https://github.com/visionmedia/commander.js
* License : MIT
  Programming Lang: Javascript
  Description : The complete solution for Node.js command-line interfaces

 Commander is a light-weight, expressive, and powerful command-line framework
 for Node.js.
 .
 Inspired by Ruby's commander, this Node.js module provides command line
 option parsing, automated/customizable help texts, command line prompting
 password query, and many more features.


-- 
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/20130509122046.7363.14543.report...@minobo.das-netzwerkteam.de

Re: Merging / and /usr

2013-05-09 Thread Timo Juhani Lindfors

Marc Haber  writes:
> Isn't that the one that doesn't even have a shell history or tab
> completion?

At least in squeeze I have both. Try booting with e.g. break=top to see
yourself.


-- 
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/848v3opc6y@sauna.l.org

Re: wheezy postmortem re rc bugfixing

2013-05-09 Thread Lucas Nussbaum

On 09/05/13 at 13:20 +0200, Julien Cristau wrote:
> On Thu, May  9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote:
> 
> > Also, we should be more agressive at getting down the number of RC bugs
> > by automatically removing RC-buggy not-so-important packages. For
> > example, if we keep the current time-based freeze policy for jessie, we
> > could announce that all not-so-important RC-buggy packages will be
> > removed from testing on freeze date.
> > 
> define:not-so-important.  I'm sure that'll be fun.

Given that:
* the "not-so-important" status would only be used to decide
  that some packages can be "safely" removed from testing when they are
  RC-buggy,
* the release team has authority on deciding what's inside testing

I think that the release team can decide on such criterias. Actually,
that's something the team already did during the wheezy freeze. I'm just
proposing to do that doing that earlier, with more advertised criterias.

For example, we could use the following rules:
* source packages with binary packages of priority 'standard',
  'important', 'required' are "important"
* source packages building udebs are "important"
* source packages building binary packages installed on more than
  5% of popcon-reporting packages (that's popcon > 7714 currently)
  are "important"
* build-dependencies of "important" packages are "important"

A quick hack resulted in:
http://udd.debian.org/cgi-bin/important_packages.cgi
http://anonscm.debian.org/gitweb/?p=collab-qa/udd.git;a=blob;f=web/cgi-bin/important_packages.cgi

Which gives 2567 such "important" packages.
Of the 963 RC bugs affecting sid currently, only 185 affect sid's
"important packages".

Lucas


-- 
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/20130509124450.ga22...@xanadu.blop.info

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Philipp Kern

On Thu, May 09, 2013 at 10:32:09AM +0200, Marc Haber wrote:
> That's how I do it for new installs. However, this is vastly more
> complex than the traditional setup, and it doesn't help for systems in
> maintenance mode that, for example, cannot be changed because of
> service level agreements and certifications.

And such systems are upgraded to a new release? That'd be surprising.

> Using Debian happens beyond single-user home desktop settings, you
> know.

I'm pretty sure he knows, so that remark seems unnecessary.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Bug#707571: ITP: node-channels -- Event channels in Node.js

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-channels
  Version : 0.0.5
  Upstream Author : Peter 'Pita' Martischka 
* URL : https://github.com/Pita/channels
* License : Apache-2.0
  Programming Lang: Javascript
  Description : Event channels in Node.js

 Channels keeps your messages in order for different endpoints (channels) of
 your Node.js application.
 .
 In Etherpad Channels is used to ensure changes for specific pads have their
 own channel (gateway) and changesets (planes) are assigned to specific
 channels (gateways).
 .
 Channels is useful if you need to have lots of different I/O operations on
 different endpoints that you need to keep in order.


-- 
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/20130509134739.587.2401.report...@minobo.das-netzwerkteam.de

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Marco d'Itri

On May 09, Marc Haber  wrote:

> If you don't care about the companies that use Debian and you want
> their sponsoring money to go elsewhere, yes, absolutely do this.
Actually I care a lot, since I happen to have a role in one which 
manages quite a bit of Debian servers (four digits of Debian servers).

And there are some interesting business reason for which I want Debian 
to support a everything-in-/usr file system.

So, please let me know if you have some technical objections better 
than "it's an hack".

-- 
ciao,
Marco

signature.asc
Description: Digital signature

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Bernhard R. Link

* Marco d'Itri  [130509 16:03]:
> So, please let me know if you have some technical objections better 
> than "it's an hack".

Having a seperate / means you have an instant rescue image that has
just the right kernel and tools you need to repair the rest of your
system. You also have one small filesystem with all the important
stuff like /etc in it while the boring large distro stuff is in
another partition. You also have a partition border between
most of the random stuff and the important stuff.

All those are real advantages that people care about. A simple
"I do it differently" or "I do not care" from your side is hardly
anything someone can counter with technical arguments, so you will
not see many.

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/20130509143822.ga4...@client.brlink.eu

Re: Doubts about PPA in Debian

2013-05-09 Thread Jeremy Stanley

On 2013-05-09 15:58:02 +0800 (+0800), Thomas Goirand wrote:
> On 05/07/2013 10:34 PM, Paul Wise wrote:
> > On Tue, May 7, 2013 at 10:12 PM, Thomas Goirand wrote:
[...]
> > > Also, the rules in backports is that packages should be
> > > already migrated to testing. The point is, if I had PPAs, I
> > > wouldn't at all upload to SID and wait for a migration to
> > > testing, because it would be better if the packages were
> > > living in the PPA only (that would be a lot more flexible and
> > > adapted to my use case).
> > 
> > I think that would be a bit sad and I hope you don't do that.
> 
> I agree. I tried to explain that to upstream, but no luck so far...
> There's not much I can do, especially with a project of that size.
[...]

To be fair, it's mostly growing pains. The project is only a few
years old at this point and has over 500 active developers (a
significant percentage of whom do it as a full-time job). There
wasn't previously as strong a focus on long-term supportability and
maintainability as the codebase grew. OpenStack doesn't officially
do development work on bug fixes for releases over a year old, but
also doesn't discourage packagers/distributors from attempting to do
so (and is generally fairly helpful at pointing them in the right
direction if the bug can be easily demonstrated).

It has also recently grown a release upgrade testing suite in its
CI, so future releases will at least provide a fully tested model
for incrementally upgrading database schemas and configuration files
from one release of OpenStack to the next. For distributions
skipping intermediate releases this probably still means carrying a
stub of the skipped releases in the next release, enough to be able
to perform upgrades... but if you'll recall at our last summit there
was also consensus around further splitting out the upgrade
mechanisms so downstreams could make easier use of them (I think you
were in the room for that conversation).
-- 
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }


-- 
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/20130509144018.gu1...@yuggoth.org

Re: epoch fix?

2013-05-09 Thread Steve Langasek

On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote:
> Looks like it might be possible to for test with lintian.

> I presume it's OK to add the implicit 0: to non-epoch depends?

> If so, lintian could complain whenever a dependency is specified on a
> package with an epoch, unless the versions specified also include an
> epoch, and if you really meant the pre-epoch version, you could just add
> the 0: to get rid of the warning.

This means the output of lintian will vary depending on what versions of the
package are visible in the local packages list.  AIUI that's something the
lintian maintainers try very hard to avoid.

-- 
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


signature.asc
Description: Digital signature

Re: Doubts about PPA in Debian

On 05/07/2013 03:34 PM, Joerg Jaspert wrote:
> While there are certainly use cases that will stay in a PPA forever
> (Thomas described one)

And I seriously wished it wasn't the case, and
that upstream understood better what the
distribution requirements are.

This should be considered as the last resort,
when there is no other way.

Thomas

-- 
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/518bb8e5.2050...@debian.org

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Bernhard R. Link

* Roger Leigh  [130509 13:34]:
> The assumptions here are that a separate rootfs decreases the chance
> of breakage, and that you'll need the rootfs to perform the rescue.

No, the point is that having two file systems reduces the amout of
breakage you get.

All the important stuff is in / while /usr is mostly static data
easily (at least outside /usr/local, and even there more likely
than say /etc) recoverable or not that important if lost.

Also with the tools in / you can usually repair problems in /usr.
There is just the right kernel and just the right versions of all
tools. You can do most of the stuff with some rescue-disc, if
the versions fits. But too often there are differences. And getting
some other tool it misses means you need to either install it in
an ramfs and hope you do not need to reboot or you need to have
some spare partition on the hw left. And you do not have access to
your fstab. While each of those problems is managable alone, they
sum up. Each adds to the time you need. And time is often something
you do not really want to spend in case you have a problem.

And while there is no proof that when having one small and one large
partition, the small partition is less likely to fail than everything
in one large partition together, both reason and experience demand
that this point is quite more than an "assumption".

> Regarding rescue, the initramfs has a rescue shell which I've found
> to be just as useful as single user mode.  Once it has mounted the
> rootfs, you can chroot into that and do whatever you would normally
> do to rescue /usr. [Assuming a separate /usr.]  If it doesn't get as
> far as mounting the rootfs, then you'll need some rescue disc in any
> case.  I find the busybox shell to be just as effective as a rescue
> disc in most cases.

"rescue /usr" in a seperate / + /usr setting usually means making sure
it can be mounted again. (Or to transfer data elsewhere, which is also
much easier when your normal network setup is already available).

> In the case where we're mounting /usr in the initramfs rather than
> having it on the rootfs, there's no practical difference to the
> current status quo (and this is intentional).  The only change is
> that we provide the guarantee that /usr is available before init
> starts.

Or in other words: to make essential functionality not available if
/usr is broken.

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/20130509150537.gb4...@client.brlink.eu

Re: Doubts about PPA in Debian

2013-05-09 Thread Jeremy Stanley

On 2013-05-09 22:55:33 +0800 (+0800), Thomas Goirand wrote:
[...]
> And I seriously wished it wasn't the case, and that upstream
> understood better what the distribution requirements are.
[...]

Actually, in this case (OpenStack) from what I've seen the upstream
community understands the distribution requirements quite well and
is, on the whole, sympathetic. It's not actively ignoring
distributor/packager concerns--the problem is there aren't enough
developers with an interest in maintaining code old enough for
distributions to carry long-term, since the current development
effort is mainly provided by donors who are interested in pulling
current code directly from the project rather than using
distribution packages (mainly because development is still moving
very, very fast compared to distributions' release schedules).

If enough interested developers suddenly walked up and asked to help
make long-term support happen (along with the additional CI
resources required, and then actually did the work), I don't think
it would be an issue. As the project ages and development stabilizes
further I hope this will begin to emerge naturally within the
developer community, and expect it will become easier to maintain
releases over longer periods of time. Right now there's just too
much code being ripped out, replaced, split into separate projects,
mashed together from separate projects and so on for that to be a
reasonable support expectation.
-- 
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }

-- 
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/20130509152953.gv1...@yuggoth.org

Re: epoch fix?

2013-05-09 Thread Jakub Wilk


* Steve Langasek , 2013-05-09, 07:39:

On Thu, May 09, 2013 at 10:43:27AM +0100, Philip Hands wrote:

Looks like it might be possible to for test with lintian.

I presume it's OK to add the implicit 0: to non-epoch depends?

If so, lintian could complain whenever a dependency is specified on a 
package with an epoch, unless the versions specified also include an 
epoch, and if you really meant the pre-epoch version, you could just 
add the 0: to get rid of the warning.


This means the output of lintian will vary depending on what versions 
of the package are visible in the local packages list.  AIUI that's 
something the lintian maintainers try very hard to avoid.


It certainly shouldn't looks at local package list. It could have a 
static data file listing all known packages with epoched versions, 
though.


And if you have data also about _past_ versions, you can implement a 
better heuristics than Philip proposed. Porting 
epoch-mistmatch-finger[0] to Lintian was on my TODO list for a while, 
but to be frank it doesn't look like I'll find time to implement this 
any time soon.


[0] http://lists.debian.org/20120705213427.ga2...@jwilk.net

--
Jakub Wilk


--
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/20130509155500.ga5...@jwilk.net

Re: Depends: libfoo:foreign ???

2013-05-09 Thread Wookey

+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
> On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote:
> > On 2013-05-09 07:56, Paul Wise wrote:
> > > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:
> > > 
> > >> I just noticed that we have the first amd64 package in the archive that
> > >> has dependencies on :i386 qualified libraries:
> > >>
> > >> Package: teamspeak-client
> 
> A Depends like in this case is never right since it mixes biarch
> (libc6-i386) packages with multiarch (libfoo:i386).

This does seem wrong, especially in this case. I can't think of a case
where it makes sense offhand, but there might be one.

> I would say that a foreign dependency on a library is never right.

That's too strong. It can make sense for cross-tools, or maybe
emulators, which genuinely need a foreign-arch library to operate. But
I'm not aware of other sensible usages.

> If
> the source compiles binaries for the foreign arch then the package
> should be build on the foreign arch directly. Period.

Apart from the above exceptions, I agree.

We haven't yet formulated any policy on what is/isn't going to be
allowed/deemed sensible. 

> Also, iirc, the use of foreign dependencies is only supposed to be on
> packages with Multi-Arch: allowed. 

I don't think that's relevant/correct. A foreign-arch dep is
appropriate when the binary is linked against/uses said library, and a
same-arch libfoo-arch-cross isn't used instead. Said library could be a
perfectly normal M-A:same package.

I guess it's time to have a think about this stuff and write down some
guidelines/policy.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.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/20130509155927.gv2...@stoneboat.aleph1.co.uk

Re: jessie release goals

2013-05-09 Thread Simon McVittie

On 06/05/13 13:49, Andreas Beckmann wrote:
> now might be the right time to start a discussion about release goals
> for jessie.

Some random "make things less fragile" ideas, from the packages that
FTBFS with the new GLib[1]:

* Packages intended to reach stable not FTBFSing just because a
  function they or their dependencies use was deprecated
  (implementation: do not use bare -Werror or
  -Werror=deprecated-declarations; do not define G_DISABLE_DEPRECATED,
  etc.; in GNOME-land, define GLIB_VERSION_MIN_REQUIRED etc.
  appropriately)

* Packages intended to reach stable not FTBFSing when the compiler
  introduces a new warning[2]
  (implementation: do not use bare -Werror, and certainly not -Wall
  -Wextra -Werror; specific "really bad things", like -Werror=implicit,
  are OK)

"Packages intended to reach stable" includes unstable/testing, but not
experimental or PPAs - it's OK, and perhaps even actively good, if
development code is liable to FTBFS at the slightest provocation.

Conversely, 64-bit-cleanness and general code quality would probably
benefit from an archive rebuild with -Werror=implicit (or some suitable
set of "bad" warnings). dpkg-buildflags already uses
-Werror=format-security.

S

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=qa-ftbfs-20130509

[2] among amusing indications that -Werror is not quite right: "byzanz:
FTBFS: record.c:59:3: error: function might be possible candidate for
'gnu_printf' format attribute [-Werror=missing-format-attribute]"


-- 
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/518bc8bc.7090...@debian.org

Re: Merging / and /usr (was: jessie release goals)

2013-05-09 Thread Marco d'Itri

On May 09, "Bernhard R. Link"  wrote:

> Or in other words: to make essential functionality not available if
> /usr is broken.
Again: this is not we are discussing. Essential functionality is moving 
to /usr anyway, no matter if /bin will become a symlink to /usr/bin.

> Having a seperate / means you have an instant rescue image that has
> just the right kernel and tools you need to repair the rest of your
> system.
OK, so you could have an even *smaller* / with a *real* independent 
rescue image like grml in /boot.

> You also have one small filesystem with all the important
> stuff like /etc in it while the boring large distro stuff is in
> another partition. You also have a partition border between
> most of the random stuff and the important stuff.
Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have 
a small filesystem with all the important stuff like /etc in it and the 
boring large distro stuff (like 100 MB of kernel modules for each 
kernel, currently in /lib) in another partition.

I am glad that we sorted out your use case as well.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: epoch fix?

2013-05-09 Thread David Kalnischkies

On Thu, May 9, 2013 at 11:43 AM, Philip Hands  wrote:
> I presume it's OK to add the implicit 0: to non-epoch depends?

No, that not okay. dpkg rewrites versions at times – mainly in
/var/lib/dpkg/status – to a "canonical" form, so this information is
lost at some point.

Especially does it cause "strange" behavior in APT: The records in
the Packages file (aka with 0:) will be different from the records in the
status file (aka without 0:) so APT will think the records talk about two
different versions of the package (as the dependencies are different).

Example:

Package: foo
Filename: foo.deb
Depends: bar (>= 0:0.00-0)

Package: foo
Status: install ok installed
Depends: bar (>= 0.0)

(And before someone asks: wontfix in APT for performance and code
 duplication with dpkg reasons, among others)

In my eyes it would actually make sense to rewrite the version in a
"canonical" form already at package creation time and warn in lintian
if a version wasn't written in the "canonical" form (as this usually indicates
a misunderstanding/bug already). Only problem I see with that is that dpkg
isn't providing an interface for it so far which lintian could use.


Best regards

David Kalnischkies


--
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/CAAZ6_fDVRw__N_qyeo=vrask96l79l535ifhthw_ctu-54w...@mail.gmail.com

Bug#707601: ITP: debmake -- helper script to make the Debian source package

2013-05-09 Thread Osamu Aoki

Package: wnpp
Severity: wishlist
Owner: Osamu Aoki 

* Package name: debmake
  Version : 4.0.0
  Upstream Author : Osamu Aoki 
* URL : 
* License : MIT
  Programming Lang: Python3
  Description : helper script to make the Debian source package

 This package helps you to convert a upstream source package (or VCS contents)
 into the Debian package by adding files required for the Debian source
 package.  The generated debian/rules file uses the new dh command syntax from
 the debhelper (>9) package.
 .
 The debmake command invoked in the upstream source tree without any option
 can generate template files which is good enough to create a single arch=any
 Debian binary package for local use.  The generated files should be edited to
 make it conform to the Debian policy if the package is uploaded to the Debian
 archive.  By adding few options, this command can generate template files for
 the arbitrary combination of the multi-binary and multi-arch package, etc.
 .
 This debmake command also scans copyright and license texts in the source
 files to help crafting the proper DEP-5 compatible debian/copyright file.


This is working here.  This generates proper dh command line with "--with ..."
for python2 and python3 (with override lines).  This also has options to use
upstream "make dist" or tarball as the starting point. I am cleaning up code
before upload.  No problem for running multiple times and no more extra
template files unless requested.

FYI:
The author thanks previous efforts on this topic (GPL):
 * debmake: 1996-1997 Christoph Lameter 
1997-2006 Santiago Vila 
command: deb-make, version up to 3.8 (shell script)
(not in wheezy)

 * dh-make: 1998-2012 Craig Small 
command: dh_make (perl script)

Version starts from 4.0.0 since old debmake was 3.8.

===
$ debmake -h
usage: debmake [-h] [-a upstream-version.tar.gz | -d] [-p package_name]
   [-u upstream_version] [-r debian_revision] [-z extension]
   [-b package[:type]] [-c license_file] [-e f...@example.org]
   [-f "firstname lastname"] [-i] [-m] [-n] [-o] [-q] [-v] [-x]

debmake: make Debian source packageVersion: 4.0.0
Copyright © 2013 Osamu Aoki 

debmake builds the Debian package from the upstream source.  
Normally, this is done as follows:
 * The upstream tarball is downloaded as the upstream-version.tar.gz file.
 * The upstream_version.orig.tar.gz symlink is generated pointing to the 
upstream tarball.
 * It is untared to create many files under the upstream-version/ directory.  
 * debmake is invoked in the upstream-version/ directory without any arguments.
 * Files in the upstream-version/debian/ directory are manually adjusted.
 * dpkg-buildpackage is invoked in the upstream-version/ directory to make 
debian packages.

optional arguments:
  -h, --helpshow this help message and exit
  -a upstream-version.tar.gz, --archive upstream-version.tar.gz
use the upstream source tarball directly (-p, -u, -z:
overridden)
  -d, --distrun "make dist" equivalent first to generate upstream
tarball and use it
  -p package_name, --package package_name
set the Debian package name
  -u upstream_version, --upstreamversion upstream_version
set the upstream package version
  -r debian_revision, --revision debian_revision
set the Debian package revision
  -z extension, --targz extension
set the tarball type,
extension=(tar.gz|tar.bz2|tar.xz)
  -b package[:type], --binaryspec package[:type]
set binary package specs,
package=(-|-doc|-dev|-common|-bin|-dbg),
type=(all|any|foreign|same)

   (This can have -b"package1:type1,package2:type2,package3:type3")

  -c license_file, --copyright license_file
add formatted license to debian/copyright
  -e f...@example.org, --email f...@example.org
set e-mail address
  -f "firstname lastname", --fullname "firstname lastname"
set the fullname
  -i, --initialize  set-up debhelper to run "autoreconf -ivf" to
initialize for Autotools
  -m, --monoarchforce packages to be non-multiarch
  -n, --native  make a native source package without .orig.tar.gz
  -o, --overwrite   overwrite existing configuration files
  -q, --quitearly   quit early before creating files in the debian
directory
  -v, --version show version information
  -x, --extra   generate extra configuration files as templates

Osamu


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with

Re: idea: generalized soft dependencies

2013-05-09 Thread David Kalnischkies

On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin wrote:
> Soft-Depends: a {90%}, b (>= 1.2) {20%}, c (>= 4) {99%}, c (>= 6) {70%}

If we assume its already hard to decide "recommends" or "suggests" it will
be impossible to choose a number between 0 and 100. Basically we are rating
likelihood of usage here and while the one provided by "a" will be a
common one for many, I am not up to the task of deciding if it will be
used by 90%, 80% or "just" 70% so naturally numbers will be assigned at
"random", which in turn means as a user I can't say: hey, install if
>= 70/80/90 as it means something different for everyone.

> Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}

So supposedly on 50% of all desktops iceweasel is installed which can
in turn be used by the software having this dependency. Great, but I still
have no idea why 50% installed it and 50% don't.
Which 50% group I am part of? The tag desktop might give a hint, but
such tags need to be defined and carry a meaning. A tag like "laptop"
tells me that it will help with powersaving (which would probably be the
better tag name, as I will like want to install it on my phone too),
"printing" is useless if I don't have a printer, "online" and "streaming"
might not be the best ideas if I have no internet connection at all …
That's a lot harder of course, but caries way more useful information as
I have no idea how many people don't have their own nuclear power plant,
highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
that in my area (and I would probably still be wrong), but not on a global
scale.

> Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}

While this solves the why, we have a new problem: Translations
And these texts are quickly written in a way a user can't use:
What the hell is a "delta"? -> debian-l10n-english to the rescue!?

Its really up to the debdelta package to tell the user what it does as in
this case it seems to be a plugin, so this should be an "Enhances" even if
from a technical point the "glue" to use debdelta is in the package the
enhances would point to.

Of course, this doesn't work if wget is used instead of debdelta in the
example as wget is used by a lot of stuff, but always for the same task:
So annotating all dependencies on wget with the tag use:downloading just
feels wrong. And the package wget is already tagged with use:downloading,
we just don't make proper use of this so far.

So in summary, I see a need for it, and I would like to reserve the syntax
we will use for build-profiles in build-dependencies also in "normal"
dependencies as use-profiles (as Johannes has already pointed to), but we
should really use the current information we already have much more and
take the new syntax we could use in ~2 releases as an override/selector
(e.g. iceweasel has 3 uses, so we could select which one is meant).

Best regards

David Kalnischkies

--
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/CAAZ6_fComDVFrVKUTmCUNDDGaMQpmxmmrSZgfGoFy=qmkvk...@mail.gmail.com

Re: New version of libselinux makes libpcre3 pseudo-essential

2013-05-09 Thread David Kalnischkies

On Wed, May 8, 2013 at 8:09 PM, Marc Haber  wrote:
> On Wed, 8 May 2013 11:56:15 +0200, Bastian Blank 
> wrote:
>>Please re-read the policy, especially 2.5:
>>| Packages must not depend on packages with lower priority values
>>| (excluding build-time dependencies).
>
> IIRC that policy paragraph is from the times where our CD build
> software didn't follow dependencies when choosing packages for images.
> Afaik, they have been following dependencies for a decade now, so this
> policy paragraph could be removed.

Please don't. Various tools might depend on it. APT will e.g. refuse to
consider "required" packages from being autoremoved and while it is
fixed since squeeze, it used to boggle on violations (#583517).
It's also using the priorities in its scoring calculations to decide which
packages are more important to keep working (granted, dependencies will
 influence it too, but every point might count).

Lifting this requirement makes priorities useless in the end as an
"optional" package which is a dependency of an "important" package
is not "optional". It must be dealt with by software as well as people
as if it is important, so lets just mark it that way – or drop priorities
completely, but not some wishy-washy middle ground.

Best regards

David Kalnischkies

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

Re: epoch fix?

On 05/08/2013 05:07 PM, Thomas Goirand wrote:
> On 05/08/2013 11:27 AM, Adam Borowski wrote:
>> On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote:
>>> What I think should be fixed is the fact that it doesn't
>>> appear in the filename. I never understood why they
>>> don't. Did I miss something?
>> Having a colon in CD/DVD images is likely to cause problems, with the chance
>> of breakage reaching 100% if there's Windows nearby.
>>
>> Not sure what a clean way of escaping the colon would be.
>>
> We don't *have* to use a semi-colon on the file names, if
> that char is a problem.
>
> Thomas
Seems nobody is picking-up on the topic, so I'll try
once more, because I'm convince there's something
we could do here. How about replacing epoch separator
char : by @ in the filenames for example?

Thomas


-- 
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/518be46b.4010...@debian.org

Bug#707615: ITP: python-autopep8 -- tool that automatically formats Python code to conform to autopep8

2013-05-09 Thread micah

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: python-autopep8
  Version : 0.8.7
  Upstream Author : Hideo Hattori 
* URL : https://pypi.python.org/pypi/autopep8
* License : Expat
  Programming Lang: Python
  Description : tool that automatically formats Python code to conform to 
autopep8

 autopep8 automatically formats Python code to conform to the PEP 8 style
 guide. It uses the pep8 utility to determine what parts of the code needs to
 be formatted. autopep8 is capable of fixing most of the formatting issues that
 can be reported by pep8.


-- 
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/20130509150714.31392.1496.report...@muck.riseup.net

Bug#707619: ITP: python-paisley -- CouchDB client written in Python to be used within a Twisted application

2013-05-09 Thread micah

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: python-paisley
  Version : 0.3.1
  Upstream Author : David Reid and Thomas Herve
* URL : https://github.com/objcode/paisley
* License : Expat
  Programming Lang: Python
  Description : CouchDB client written in Python to be used within a 
Twisted application

 Paisley implements the CouchDB API for Twisted.


-- 
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/20130509152120.1002.77317.report...@muck.riseup.net

Bug#707620: ITP: python-dirspec -- Python User Folders Specification Library

2013-05-09 Thread Micah Anderson

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: python-dirspec
  Version : 4.2.0
  Upstream Author : Canonical Ltd.
* URL : https://launchpad.net/dirspec
* License : LGPL-3
  Programming Lang: Python
  Description : Python User Folders Specification Library

 A library for handling the XDG Base Directory specification, and the
 XDG User Directories for music, videos, 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/20130509155316.12651.46511.report...@muck.riseup.net

Bug#707625: ITP: u1db -- Ubuntu One structured data storage - Python API

2013-05-09 Thread Micah Anderson

Package: wnpp
Severity: wishlist
Owner: Micah Anderson 

* Package name: u1db
  Version : 0.1.4
  Upstream Author : Canonical Ltd
* URL : https://launchpad.net/u1db
* License : LGPL-3
  Programming Lang: Python, C
  Description : Ubuntu One structured data storage - Python API

U1DB is a database API for synchronised databases of JSON documents. It’s
simple to use in applications, and allows apps to store documents and
synchronise them between machines and devices. U1DB itself is not a database:
instead, it’s an API which can be backed by any database for storage. This
means that you can use U1DB on different platforms, from different languages,
and backed on to different databases, and sync between all of them. It's built
to sync with your own servers or with Ubuntu One.


-- 
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/20130509183819.15506.65409.report...@muck.riseup.net

Re: can someone explain what is happen on line one from this listing?

2013-05-09 Thread Istimsak Abdulbasir

It seems you have a faulty hard disk.

Istimsak abdulbsir
On May 9, 2013 7:47 AM, "Mailbox"  wrote:

> Hello Developer Group,
>
> can someone explain what is happen on line one from this listing?
>
> why i loos the interrupt?
>
> what is the Status 0x50?
>
> has someone a idea in which Documentation an can finde more informations
> about 0x50?
>
> May  7 19:39:57 lxhs110a kernel: [316946.812055] ata2: lost interrupt
> (Status 0x50)
> May  7 19:39:57 lxhs110a kernel: [316946.812072] ata2: exception Emask
> 0x10 SAct 0x0 SErr 0x4405 action 0xf
> May  7 19:39:57 lxhs110a kernel: [316946.812116] ata2: SError: { PHYRdyChg
> CommWake DevExch }
> May  7 19:39:57 lxhs110a kernel: [316946.812156] ata2: hard resetting link
> May  7 19:39:58 lxhs110a kernel: [316947.536038] ata2: SATA link up 1.5
> Gbps (SStatus 113 SControl 300)
> May  7 19:39:58 lxhs110a kernel: [316947.560823] ata2.00: configured for
> UDMA/133
> May  7 19:39:58 lxhs110a kernel: [316947.560831] end_request: I/O error,
> dev sdb, sector 25141733
> May  7 19:39:58 lxhs110a kernel: [316947.560876] md: super_written gets
> error=-5, uptodate=0
> May  7 19:39:58 lxhs110a kernel: [316947.560880] raid1: Disk failure on
> sdb4, disabling device.
> May  7 19:39:58 lxhs110a kernel: [316947.560881] raid1: Operation
> continuing on 1 devices.
> May  7 19:39:58 lxhs110a kernel: [316947.560962] ata2: EH complete
> May  7 19:39:58 lxhs110a kernel: [316947.595196] RAID1 conf printout:
> May  7 19:39:58 lxhs110a kernel: [316947.595198]  --- wd:1 rd:2
> May  7 19:39:58 lxhs110a kernel: [316947.595201]  disk 0, wo:1, o:0,
> dev:sdb4
> May  7 19:39:58 lxhs110a kernel: [316947.595203]  disk 1, wo:0, o:1,
> dev:sda4
> May  7 19:39:58 lxhs110a kernel: [316947.608009] RAID1 conf printout:
> May  7 19:39:58 lxhs110a kernel: [316947.608011]  --- wd:1 rd:2
> May  7 19:39:58 lxhs110a kernel: [316947.608013]  disk 1, wo:0, o:1,
> dev:sda4
>
> thanks
> Paulo
>
>
> --
> To UNSUBSCRIBE, email to 
> debian-devel-REQUEST@lists.**debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/**518b8c73.20...@ai-t.eu
>
>

Re: Depends: libfoo:foreign ???

2013-05-09 Thread Steve Langasek

On Thu, May 09, 2013 at 08:43:22AM +0200, Niels Thykier wrote:
> On 2013-05-09 07:56, Paul Wise wrote:
> > On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:

> >> I just noticed that we have the first amd64 package in the archive that
> >> has dependencies on :i386 qualified libraries:

> >> Package: teamspeak-client

> > It appears that will block it from reaching testing:

> Indeed, Britney does not support those annotations (at the moment?).  To
> avoid issues with this kind of thing, we made her consider such
> dependencies for unsatisfiable[1].
>   So for now anything using that form in Depends or Pre-Depends will not
> reach testing (without manual intervention from the Release team and I
> am not sure how likely "we" are to do that).

Sorry for not knowing the answer to this, but does britney support :any
dependencies?  These don't require any cross-architecture dependency
resolution, but should be satisfiable within each architecture; britney just
needs to support them.

This would let us finally make use of Multi-Arch: allowed in the archive.

-- 
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


signature.asc
Description: Digital signature

Re: idea: generalized soft dependencies

2013-05-09 Thread Eugene V. Lyubimkin

Hi,

Thank you for comments.

2013-05-09 18:44, David Kalnischkies:
> On Wed, May 8, 2013 at 8:51 PM, Eugene V. Lyubimkin  wrote:
> > Soft-Depends: a {90%}, b (>= 1.2) {20%}, c (>= 4) {99%}, c (>= 6) {70%}
> 
> If we assume its already hard to decide "recommends" or "suggests" it will
> be impossible to choose a number between 0 and 100. Basically we are rating
> likelihood of usage here and while the one provided by "a" will be a
> common one for many, I am not up to the task of deciding if it will be
> used by 90%, 80% or "just" 70% so naturally numbers will be assigned at
> "random", which in turn means as a user I can't say: hey, install if
> >= 70/80/90 as it means something different for everyone.

Interesting view. I saw it from exactly opposite direction: one
maintainer sees Recommends as '>95%' and another as '>60%'. I as
maintainer would have much easier time with writing percents or other
attribute criteries than putting all different stuff into two
categories, YMMV. 70% and 80% are close to each other, true, but 90% and
99% are two different things, and using current rules I'd put both to
Recommends. Many maintainers put "99%"-stuff" to Depends because users
cannot command "disable '<90%'-Recommends" so they command "disable all
Recommends". This is (part of) what I am trying to solve.

tl;dr: I would want to be able to differentiate between, for example,

- "install this or your system will break (unless you did special things so it 
does not)";
- "install this unless you know you'll never need this feature";
- "this things is worth installing by default".

> > Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
> 
> So supposedly on 50% of all desktops iceweasel is installed which can
> in turn be used by the software having this dependency. Great, but I still
> have no idea why 50% installed it and 50% don't.

It was an example of maintainer guessing that half of users of some
software will want also iceweasel installed, provided the computer "is
desktop".

> Which 50% group I am part of? The tag desktop might give a hint, but
> such tags need to be defined and carry a meaning. A tag like "laptop"
> tells me that it will help with powersaving (which would probably be the
> better tag name, as I will like want to install it on my phone too),
> "printing" is useless if I don't have a printer, "online" and "streaming"
> might not be the best ideas if I have no internet connection at all …
> That's a lot harder of course, but caries way more useful information as
> I have no idea how many people don't have their own nuclear power plant,
> highspeed internet or a printer. 30, 50 or 90% ? I might be able to answer
> that in my area (and I would probably still be wrong), but not on a global
> scale.

I don't propose any specific attribute. I propose to have an ability to later
discuss and standardize these attributes.

> > Soft-Depends: debdelta {10%,text:"to enable automatic delta downloading"}
> 
> While this solves the why, we have a new problem: Translations
> And these texts are quickly written in a way a user can't use:
> What the hell is a "delta"? -> debian-l10n-english to the rescue!?
[...]

You speak about problems of a specific example attribute. We might use
text: attribute, we might not use is. Unless your point is say that
(all) attributes don't help (and therefore the proposal doesn't make the
situation better), this is not what proposal is about.

> Of course, this doesn't work if wget is used instead of debdelta in the
> example as wget is used by a lot of stuff, but always for the same task:
> So annotating all dependencies on wget with the tag use:downloading just
> feels wrong. And the package wget is already tagged with use:downloading,
> we just don't make proper use of this so far.

Sounds like I had not enough good example if you feel this was about
'use:downloading'. The idea of this example was not to repeat packages
descriptions, but say how the soft dependency will help exactly this
package in question. This one should illustrate better:

libcupt2-0: Soft-Depends: ed (text:"to enable downloading PDiffs")

> [...] we should really use the current information we
> already have much more [...]

I kind of disagree here. Currently we have zero dependency-specific
information apart of a) what group of Depends/Recommends/Suggests the
maintainer put the dependency to b) possible free-form explanations in
long descriptions or other package documentation.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer

-- 
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/20130509192458.GB4105@debian-w500.Elisa

Re: idea: generalized soft dependencies

2013-05-09 Thread Eugene V. Lyubimkin

Hi,

2013-05-09 09:01, Johannes Schauer:
> [...]
> Soft-Depends: a [minthresh:90], b (>= 1.2) [minthresh:20], c (>= 4) 
> [minthresh:99], c (>= 6) [minthresh:70]
> Soft-Depends: iceweasel [minthresh:50 tag:desktop], curl [minthresh:95 
> !installed:wget]

Indeed, this syntax would be just as good.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer


-- 
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/20130509192734.GC4105@debian-w500.Elisa

Debian development and release: always releasable (essay)

2013-05-09 Thread Lars Wirzenius

This is from Russ Allbery and myself.  See http://wiki.debian.org/Debate
for context, and http://wiki.debian.org/AlwaysReleasableTesting for
the canonical version of this essay. We hope that the readers will take
their time to read this, reflect on it, and then maybe write their own
essay and add it to http://wiki.debian.org/JessieReleaseProcess .
Comments on the wiki or by e-mail are, of course, always welcome.

 - - -

The wheezy freeze has been much too long. At ten months, it's four
months longer than what we've gotten used to in several previous
releases. Had we managed to keep the freeze at six months, it would
still have been too long. I believe there is something wrong in how
we develop Debian, and how we do releases, and that by fixing them,
we can have much shorter releases, with an increase in their quality.

Freezes are long in part because we need to do so much work during
them. Most importantly, we need to fix so many release critical bugs
(RC bugs), that a short freeze is not possible, without drastically
lowering the quality of Debian.

A long freeze is highly frustrating to everyone. It's a very stressful
period for the release team, obviously, but since the freeze affects
all development, even those of our developers who do not care about
the release feel its effects in their development. Our users would
like fresh upstream versions, but that rarely happens in unstable,
and because the freeze is so long, when the release actually happens,
much software seems a bit stale. Upstreams, who would like to get
their software into the hands of users as soon as possible, including
via Debian, are also frustrated.

We should aim for a short freeze, perhaps as short as two weeks,
and certainly not longer than two months. This would remove the
frustration, and fix the other problems related to a long freeze.
However, to achieve a short freeze, we need to change how develop
Debian.

The fundamental change is to start keeping our "testing" branch
as close to releasable as possible, at all times. For individual
projects, this corresponds to keeping the master or trunk branch
in version control ready to be released. Practitioners of agile
development models, for example, do this quite successfully, by
applying continuous integration, automatic testing, and by having
a development culture that if there's a severe bug in master,
fixing that gets highest priority.

We can do similar things in Debian, and if we do, I believe that we
can keep testing in a releaseable state almost all of the development
cycle between two releases. The minimum necessary changes to achieve
this, in my opinion, are:

* An attitude change: we decide that releases are important, and that
  they're the job of the entire project, not just the release team.
* Keep testing free of RC bugs.
* We should use automatic testing much more extensively, to find
  problems as early as possible.
* We should limit the number of packages we strongly care about for
  a release.

Releases are important
--

Releases are important to many, perhaps most, of our users. Hackers
and hardcore powerusers don't necessarily care about them, of course,
but most others do. A released version of Debian implies that the
operating system works: there's a working installer, for example.
It also implies that all the packages are expected to work together:
there's no transitions going on, for example, that might break
dependencies or reverse dependencies.

A release is important to many users because it means that if they
have to re-install, they will get back the same system they used to
have. Or they can install another computer that will behave the same
way as the first one. This reproducibility is also why enterprises
like them: they can confidently assume that if they install fifty
thousand machines, they'll all be the same. Without this kind of
uniformity, system administration costs, and end-user support costs,
become unmanageable.

But releases are also important for us, as a project. They're an
excellent point to stop and say, "we have achieved this, and it is
good". It's a reason for others to have a look at Debian and see that
it is good. This generates a good feeling, which gives us more
motivation to work on Debian.

It's true that we can't expect every Debian developer to care about
making a release. That's OK. We just need the minority who don't care
to not get in the way of the release.

Keep testing free of RC bugs


The RC bug count for the testing branch should be kept low all the
time. Right after a release, by definition, testing is free of RC
bugs. With the current development model, right after the release we
open the floodgates, and large number of new packages and versions
enter testing. The bug count sky-rockets, but we don't care a lot
about that until the next freeze gets closer.  This means testing
is not anywhere near in a releasable condition during most of the
development cycle.

We shoul

Re: Depends: libfoo:foreign ???

2013-05-09 Thread Niels Thykier

On 2013-05-09 21:00, Steve Langasek wrote:
> [...]
> 
> Sorry for not knowing the answer to this, but does britney support :any
> dependencies?  These don't require any cross-architecture dependency
> resolution, but should be satisfiable within each architecture; britney just
> needs to support them.
> 
> This would let us finally make use of Multi-Arch: allowed in the archive.
> 

At the moment, no.  We had her treat "pkg:arch" as a package name
causing it to always fail (as no package can have colon in their name).
  But feel free to file bugs for it (bonus points if they include tests[1]).

~Niels

[1]
http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git;a=summary



-- 
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/518bffcf.6060...@thykier.net

Re: DPA instead of PPA

2013-05-09 Thread Steve McIntyre

In article <518b7cf6.3080...@debian.org> you write:
>On 09/05/13 07:38, Raphael Hertzog wrote:
>> bikeshed \o/
>
>You probably meant this to be a comment on the discussion rather than a
>suggested name, but "until it gets uploaded to unstable, you can get
>GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a
>reasonable sentence to write. :-)

+1 for the "bikeshed" name. I think it's a *perfect* fit! :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.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/e1uax48-jr...@mail.einval.com

Re: can someone explain what is happen on line one from this listing?

2013-05-09 Thread Ben Hutchings

On Thu, May 09, 2013 at 01:45:55PM +0200, Mailbox wrote:
> Hello Developer Group,
> 
> can someone explain what is happen on line one from this listing?
[...]

This is off-topic; you should ask on the debian-user list or other
support channel.

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/20130509201726.gd6...@decadent.org.uk

Bug#707640: ITP: node-security -- Safely encoding and decoding methods with Node.js

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-security
  Version : 1.0.0
  Upstream Author : Chad Weider 
* URL : https://github.com/cweider/js-security
* License : Expat
  Programming Lang: Javascript
  Description : Safely encoding and decoding methods with Node.js

 Safely encode/decode HTML, Javascript and CSS data compliant to the standard
 as demanded by the OWASP when using Node.js.


-- 
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/20130509201530.27625.20872.report...@minobo.das-netzwerkteam.de

Re: Debating difficult development issues in essay form

2013-05-09 Thread Svante Signell

On Thu, 2013-05-09 at 20:45 +0100, Lars Wirzenius wrote:
> This e-mail is jointly from Lars Wirzenius and Russ Allbery.
> The executive summary: We'd like to see more thoughtful debates
> of important Debian development issues, and have created
>  as a way to encourage them.

A very good initiative. I hope it takes off. Looking forward to the
posts there instead of at debian-devel.



-- 
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/1368131548.4595.37.camel@PackardBell-PC

Bug#707642: ITP: node-node-redis -- Redis client implementation for Node.js

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-node-redis
  Version : 0.1.6
  Upstream Author : Tim Smart 
* URL : https://github.com/tim-smart/node-redis
* License : Expat
  Programming Lang: Javascript
  Description : Redis client implementation for Node.js

 Redis is a networked, in-memory, key-value data store with optional durability.
 .
 This module provides Redis client support for Node.js.


-- 
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/20130509203247.32331.28859.report...@minobo.das-netzwerkteam.de

Re: Developer repositories for Debian

2013-05-09 Thread Russ Allbery

Raphael Hertzog  writes:
> On Mon, 06 May 2013, Joerg Jaspert wrote:

>> Nah, the webinterface just should end up like the DAM webinterface: You
>> do whatever you need, then click a button - and voila, there is
>> everything ready to copy/paste into a MUA. Send with sig, done.

> Why? This is just a band-aid and not what I would call a web interface.
> And except lazyness I don't see a good reason for that. Web interfaces
> can be secure (and with an audit trail in case of breach). After all we
> can manage our Debian passwords over a web interface...

That level of security isn't great, though.  GPG keys are much more secure
than that password.  What we would want for equivalent security in a web
interface is personal X.509 certificates.

I think it would be interesting to have that infrastructure in place, but
someone would need to build it (probably with some mechanism to bootstrap
GPG keys into X.509 certificates -- and be careful of expiration times and
figure out a good way to deal with revocation).

-- 
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/87haibnb9y@windlord.stanford.edu

Re: Debian development and release: always releasable (essay)

2013-05-09 Thread Vincent Bernat

 ❦  9 mai 2013 21:49 CEST, Lars Wirzenius  :

> * Remove RC buggy packages sooner rather than later. An RC buggy
>   package should be removed at soon as possible: when the bug
>   is identified, allow a bit of time for the bug to be verified
>   (was it actually an RC bug?), but after that, remove the package
>   from testing, preferably automatically.  If the package has
>   reverse dependencies, remove those as well. This keeps testing
>   releasable. The removed package can and will re-enter testing once
>   it gets fixed.

I think that's a very good idea. A threshold on the number of source
packages that can be removed from testing due to an RC bug could be
something like 10. The release team should be entitled to delay the
removal if the bug is quite complex.

I think that the other things you propose are too complicated:

> A package that is not included in one or more of the reference
> installations is a package we want to include in the release, but we
> will not delay the release for its sake. We should have a low threshold
> for removing such a package from testing: it could perhaps even be
> removed automatically one week after an RC bug is filed against it
> (assuming the bug affects the version in testing).

If a package is important, an RC bug will get noticed and someone will
step to fix the RC bug or ask for a delay. This avoids unnecessary
debate on what is important and what is not and people fighting to get
their packages in the right list.

> Tests for running reference installation might include the following:
>
> * Basic networking setup works: System responds to ping from the outside.
> * Mail server responds appropriate on the SMTP, submission, IMAPS, and POPS
>   ports.
> * LAMP server responds on the HTTP and HTTPS ports.
> * A desktop system that automatically logs in a test user has the right
>   processes running, and can start some common applications.
> * In each case, it's possible to log in remotely with ssh and run
>   "sudo apt-get install hello".

Many people run unstable and a bug that would fail those kind of tests
would get immediatly noticed and many bug reports are usually opened at
once for each of those bugs. Maybe those tests would catch them one hour
earlier but is it worth spending time to conceive those tests?

> These are trivial, even simplistic tests. However, if they pass, we know
> that at least the basic, fundamental things in the system are not horribly
> broken: networking, system administration, and the software that is meant
> to start in that reference installation. Furthermore, we know that the
> debian-installer works. That's a good foundation for further hacking.

Maybe the installer is less daily tested but did we already have a major
bug (one that does not pass the test you described) gone unnoticed?
-- 
 /*
  *   Should be panic but... (Why are BSD people panic obsessed ??)
  */
2.0.38 /usr/src/linux/net/ipv4/ip_fw.c


pgpQIIIqPZawA.pgp
Description: PGP signature

Re: New version of libselinux makes libpcre3 pseudo-essential

2013-05-09 Thread Russ Allbery

Игорь Пашев  writes:

> Will it change anything except non-linux systems will get libpcre3 by
> default, while do not need it?

> Maybe make libselinux optional? ;-)

windlord:~> apt-cache rdepends libselinux1 | tail
  libglib2.0-0
  gdm3
  dump
  dpkg
  dmraid
  dbus-1-dbg
  dbus
  cron
  coreutils
  aide-dynamic

No.  :)

-- 
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/87d2sznb1z@windlord.stanford.edu

Bug#707643: ITP: python-grokmirror -- Framework to smartly mirror git repositories

2013-05-09 Thread Adrian Alves

Package: wnpp
Severity: wishlist
Owner: Adrian Alves 

* Package name: python-grokmirror
  Version : 0.3
  Upstream Author : Konstantin Ryabitsev 
* URL : https://git.kernel.org/cgit/utils/grokmirror/grokmirror.git
* License : GPL
  Programming Lang: Python
  Description : Framework to smartly mirror git repositories

Grokmirror was written to make mirroring large git repository
collections more efficient. Grokmirror uses the manifest file published
by the master mirror in order to figure out which repositories to
clone, and to track which repositories require updating. The process is
extremely lightweight and efficient both for the master and for the
mirrors.


-- 
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/20130509203847.6826.85548.reportbug@xion

Re: Debian development and release: always releasable (essay)

2013-05-09 Thread Russ Allbery

Vincent Bernat  writes:
>  ❦  9 mai 2013 21:49 CEST, Lars Wirzenius  :

>> A package that is not included in one or more of the reference
>> installations is a package we want to include in the release, but we
>> will not delay the release for its sake. We should have a low threshold
>> for removing such a package from testing: it could perhaps even be
>> removed automatically one week after an RC bug is filed against it
>> (assuming the bug affects the version in testing).

> If a package is important, an RC bug will get noticed and someone will
> step to fix the RC bug or ask for a delay. This avoids unnecessary
> debate on what is important and what is not and people fighting to get
> their packages in the right list.

Personally, I think it's important to be more transparent and systematic
about how we designate packages as important or not important; it will add
clarity and it will let us be more efficient and encourage people to be
bold.  The fact of the matter is that we already have those distinctions:
we will remove random leaf packages from testing as soon as the release
gets close, but we're not going to remove cron or bash.  But the
distinctions are fuzzy and require people to make (and then argue about)
judgement calls.  We can't eliminate the arguments entirely, but I think
we can approach the process in a cleaner way that will require less
constant debate.

Package sets for critical purposes are useful in their own right.  They
make it clear why a package is important (and also why it may *cease* to
be important), and they also provide a basis for automated testing.

Personally, I'd be inclined to unify optional and extra (which at this
point don't really represent a meaningful difference) and possibly even
further simplify our use of priorities (it's not clear to me that standard
is really buying us anything any more), replacing most of that with
package sets for key use cases that we want to support.

One interesting possibly that this would also open up (and please
understand that I don't know if this would happen and I'm not positive
that it's a good idea; I'm just throwing it out there) is that the teams
who most care about a particular reference package set could also do some
of the release management duties for that package set.  For example,
suppose we had a LAMP team of experts in that package set.  Could they
possibly take on, not just maintaining the list of packages, but doing
freeze reviews and transition coordination for transitions that are
contained within that set?

To some extent, the desktop packaging groups (GNOME, KDE, etc.) already do
some of this for those desktop environments, and I think that's quite
helpful and might be useful to formalize further.

> Many people run unstable and a bug that would fail those kind of tests
> would get immediatly noticed and many bug reports are usually opened at
> once for each of those bugs. Maybe those tests would catch them one hour
> earlier but is it worth spending time to conceive those tests?

Yes, absolutely.  Because when you have the tests, it opens up all sorts
of possibilities for automation.  For example, you could, in the future,
put newly-uploaded packages in a holding area until the tests pass and not
allow them into the archive until they do.

Breakage bugs in unstable are very valuable, but they also represent
*breakage* and take someone's time and attention to write up.  Anything we
can catch on an automated basis saves precious human resources.

>> These are trivial, even simplistic tests. However, if they pass, we
>> know that at least the basic, fundamental things in the system are not
>> horribly broken: networking, system administration, and the software
>> that is meant to start in that reference installation. Furthermore, we
>> know that the debian-installer works. That's a good foundation for
>> further hacking.

> Maybe the installer is less daily tested but did we already have a major
> bug (one that does not pass the test you described) gone unnoticed?

We've had system-breaking bugs in core packages like libc6 enter the
archive in the past.  They don't make it through to testing, no, but they
do take up people's time and attention in unstable, and it's all more
resources that we can't spend on other things that are more useful.  And,
over time, the tests can become more sophisticated.  That's the great part
about building a testing framework: once you have a good framework in
place, it becomes much easier to add more tests, and you can build
something like Lintian (which is now quite extensive) from a modest
beginning.

-- 
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/8761yrn9sf@windlord.stanford.edu

Bug#707656: ITP: node-node-dequeue -- Simple Double Ended Queue Datastructure for Node.js

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-node-dequeue
  Version : 1.0.3
  Upstream Author : Sean (lleo) M. Egan 
* URL : https://github.com/lleo/node-dequeue
* License : BSD-2-clause
  Programming Lang: Javascript
  Description : Simple Double Ended Queue Datastructure for Node.js

 Dequeue is implemented as a doubly linked circular list with a titular
 head node--an empty node to designate the beginning and the end of the
 circularly linked list.
 .
 It is a drop-in replacement for javascript-arrays-as-fifo.


-- 
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/20130509233319.7965.319.report...@minobo.das-netzwerkteam.de

Work-needing packages report for May 10, 2013

2013-05-09 Thread wnpp

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 512 (new: 9)
Total number of packages offered up for adoption: 139 (new: 5)
Total number of packages requested help for: 64 (new: 3)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   elilo (#707112), orphaned 2 days ago
 Description: Bootloader for systems using EFI-based firmware
 Reverse Depends: bootcd-ia64
 Installations reported by Popcon: 141

   hsqldb (#707122), orphaned 2 days ago
 Reverse Depends: biomaj entagged eucalyptus-java-common
   hsqldb-server hsqldb-utils libbiojava1.7-java libbiojava3.0-java
   libhsqldb-java-gcj libopenjpa-java libreoffice-base (3 more omitted)
 Installations reported by Popcon: 71234

   ko.tex (#707573), orphaned today
 Description: Korean TeX: Core macros
 Reverse Depends: ko.tex
 Installations reported by Popcon: 25

   ko.tex-extra-hlfont (#707574), orphaned today
 Description: Korean TeX: Extra HLaTeX fonts
 Installations reported by Popcon: 3275

   ko.tex-unfonts (#707575), orphaned today
 Description: Korean TeX: Base fonts
 Reverse Depends: ko.tex
 Installations reported by Popcon: 37

   libapache-mod-layout (#707149), orphaned 2 days ago
 Description: Apache web page content wrapper
 Installations reported by Popcon: 51

   libapache-mod-random (#707143), orphaned 2 days ago
 Description: Create random ads, quotes and redirects
 Installations reported by Popcon: 20

   sampleicc (#707334), orphaned today
 Reverse Depends: libicc-utils-dev libsampleicc-dev sampleicc-tools
 Installations reported by Popcon: 70

   ttf-alee (#707576), orphaned today
 Description: free Hangul TrueType fonts
 Reverse Depends: sdl-ball-data
 Installations reported by Popcon: 1190

503 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   ant-phone (#707572), offered today
 Description: An interactive ISDN telephone application
 Installations reported by Popcon: 12

   dawgdic (#706886), offered 4 days ago
 Description: C++ library for DAWG dictionaries
 Installations reported by Popcon: 9

   libb64 (#706894), offered 4 days ago
 Description: base64 encoding/decoding library
 Reverse Depends: libb64-dev
 Installations reported by Popcon: 6

   python-dawg (#706887), offered 4 days ago
 Description: Python library for DAWG dictionaries
 Installations reported by Popcon: 1

   sentinella (#707649), offered today
 Description: System monitor that can react to user chosen conditions
 Installations reported by Popcon: 134

134 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

[NEW] openmx (#706711), requested 6 days ago
 Installations reported by Popcon: 178

[NEW] openni2 (#707056), requested 2 days ago
 Description: Debian package for openni version 2 software from
   OpenNi.org

[NEW] parmetis (#706710), requested 6 days ago (non-free)
 Reverse Depends: libparmetis-dev libsuitesparse-metis-3.1.0
   libsuitesparse-metis-dbg libsuitesparse-metis-dev parmetis-test
 Installations reported by Popcon: 218

   apt-xapian-index (#567955), requested 1193 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 79336

   asymptote (#517342), requested 1532 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4821

   athcool (#278442), requested 3117 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 66

   balsa (#642906), requested 592 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 932

   bastille (#592137), requested 1006 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 188

   cardstories (#624100), requested 745 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 9

   chromium-browser (#583826), requested 1075 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-

Re: DPA instead of PPA

2013-05-09 Thread Henrique de Moraes Holschuh

On Thu, 09 May 2013, Steve McIntyre wrote:
> In article <518b7cf6.3080...@debian.org> you write:
> >On 09/05/13 07:38, Raphael Hertzog wrote:
> >> bikeshed \o/
> >
> >You probably meant this to be a comment on the discussion rather than a
> >suggested name, but "until it gets uploaded to unstable, you can get
> >GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a
> >reasonable sentence to write. :-)
> 
> +1 for the "bikeshed" name. I think it's a *perfect* fit! :-)

At least for "PPAEXT", it really fits...

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

Re: Current and upcoming toolchain changes for jessie

2013-05-09 Thread Chow Loong Jin

On 09/05/2013 06:06, Florian Weimer wrote:
> I mistyped, I meant ABI.  I'm deeply sorry about that, it mangles my
> statement quite badly.
> 
> AFAIK, this is the major reason why the C++11 support is still marked
> as experimental.

C++ never had a set ABI in the standard. It's up to compiler/toolchain/library
writers to ensure that there aren't ABI breakages. Considering that you still
link against the same libstdc++.so.6 regardless of whether or not you use C++11
features, I don't see how avoiding C++11 features will avoid triggering a
mass-rebuild in the event of an ABI break in libstdc++6.

> std::string, std::list and probably std::shared_ptr will have to
> change ABI at some point.

When that happens, it'll probably be namespaced somehow, because the C++98
std::{string,list,shared_ptr}'s will still have to stay. Then C++11 programs
compiled against older libstdc++ will just continue to use the C++98
std::{string,list,shared_ptr} and remain binary-compatible. No recompilation
required there.

-- 
Kind regards,
Loong Jin

signature.asc
Description: OpenPGP digital signature

Re: Developer repositories for Debian

On Fri, May 10, 2013 at 4:33 AM, Russ Allbery wrote:

> That level of security isn't great, though.  GPG keys are much more secure
> than that password.  What we would want for equivalent security in a web
> interface is personal X.509 certificates.
>
> I think it would be interesting to have that infrastructure in place, but
> someone would need to build it (probably with some mechanism to bootstrap
> GPG keys into X.509 certificates -- and be careful of expiration times and
> figure out a good way to deal with revocation).

That mechanism already exists (and supports SSH too):

http://web.monkeysphere.info/

The monkeysphere developers are Debian folks and have discussed
monkeysphere with DSA at various DebConfs.

-- 
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/CAKTje6FhKHGd7MVZ30zu6M_=okbsyenis1p8ptaak7gqcvl...@mail.gmail.com

Re: New version of libselinux makes libpcre3 pseudo-essential

On Fri, May 10, 2013 at 4:38 AM, Russ Allbery wrote:
> Игорь Пашев writes:
>
>> Will it change anything except non-linux systems will get libpcre3 by
>> default, while do not need it?
>
>> Maybe make libselinux optional? ;-)
>
> windlord:~> apt-cache rdepends libselinux1 | tail
...
> No.  :)

Since it is Linux-specific, it is already optional on kFreeBSD so
there is probably nothing for Игорь Пашев to do on his Debian and
Solaris based system.

pabs@asdfasdf:~$ apt-cache rdepends libselinux1


-- 
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/CAKTje6ENkhBtOyyfRVcW=rgT462CLndMXyekySEW=Z1T=ib...@mail.gmail.com

Re: DPA instead of PPA

2013-05-09 Thread Charles Plessy

Le Thu, May 09, 2013 at 08:38:02AM +0200, Raphael Hertzog a écrit :
> Hi,
> 
> On Wed, 08 May 2013, Holger Levsen wrote:
> > I actually really like this idea! (Though I suggest "Debian Personal 
> > Archive".)
> > 
> > It's really different from what people know as PPAs.
> 
> To be fair, "Personal" is probably not relevant either. I expect many of
> those repositories to be maintained by teams.
> 
> DSPA = Debian Special Purpose Archive
> DSPR = Debian Special Purpose Repository
> DASP = Debian Archive of Special Packages
> SPA = Special Package Archive

Hi all,

Fist of all, many thanks to Joerg and the FTP team to push this project
forward.  I find it exciting and innovative and I like that it is not simply
reproducing Ubuntu's PPAs, but rather aims at providing a direct benefit to
Debian's development in general.  For this reason, I also recommend to avoid
using "PPA" in the name.

About the names discussed by Raphael and others, I also think that "personal"
does not reflect well the goals suggested for "PPAMAIN".  Keywords like
"Special", "Project", etc., sound to me more to the point.

For "SPA" in particular, I think that would trigger puns in French, as is the
name of a society that, among others, takes care of abandonned animals.

Also, since PPAMAIN will be embedded in the Debian archive, maybe there is no
need to repeat "Debian" in its name.

I also would like to recommend to call these repositories in a way that shows
directly how they are integrated in the archive.  For instance "distribution"
if it is one more entry in "/dists", and "area" or "pool" if it is one more
entry in "/pool".

Have a nice day,

-- 
Charles

PS: the bikeshed of the building where I live was repainted last year, and I
did not propose a new color :)

-- 
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/20130510043456.gb23...@falafel.plessy.net

Re: Debian development and release: always releasable (essay)

On Fri, May 10, 2013 at 3:49 AM, Lars Wirzenius wrote:

> * An attitude change: we decide that releases are important, and that
>   they're the job of the entire project, not just the release team.

I already believe that. I would find it quite surprising if people
actually believe that releases are solely the job of the release team.
Do you have any data about what proportion of Debian contributors
don't believe that?

Folks obviously care about stable to varying levels though, some
probably don't even use stable.

> * Keep testing free of RC bugs.

I keep packages I (co-)maintain free of RC bugs.

> * We should use automatic testing much more extensively, to find
>   problems as early as possible.

I already do pay attention to that. I look at PTS pages before doing
uploads and run a bunch of automated tests before uploading or sending
a package review on debian-mentors. I also try to remember check sites
with QA/etc info that aren't yet integrated into the PTS (like the
derivatives patches).

http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

> * We should limit the number of packages we strongly care about for
>   a release.

I don't agree with this.

> * Remove RC buggy packages sooner rather than later. An RC buggy
>   package should be removed at soon as possible: when the bug

The release team already do this using a semi-automated method.

> We should have an explicit list of such reference installations
> and declare them as crucial for the release:

How about:

all the tasks
all the blends

> if they work, we can release, and if they don't, we can't.

How would you define "work"?

Presumably: no RC bugs, no piuparts issues?

> Use automatic testing extensively
> -
>
> We have some automatic testing tools specifically for Debian: lintian,
> piuparts, adequate, autopkgtest, and probably more. We should use
> these much more extensively, and let them guide the migration of
> packages into testing.

Some more automatic tests folks might like to run:

http://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package

> Imagine a continuous integration system for Debian: for every new
> package upload to unstable, it builds and tests all the reference
> installations.  If all builds succeed, and all tests pass, the package
> can be moved into testing at once. When you, a developer, upload a
> new package, you get notified about test results, and testing migration,
> within minutes.

Different tests are more important than others. I don't think every
test is important enough to block testing migration. The only tests I
can think of that should do that are puiparts failures.

Thanks for your thoughts, hopefully the release team will be willing
to adopt some of them, especially the puiparts failures one.

-- 
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/CAKTje6HWdxgFjDJapAc_+eUjmC+U6X=N5q+_ffqUnreR-=z...@mail.gmail.com

Re: Developer repositories for Debian

2013-05-09 Thread Raphael Hertzog

On Fri, 10 May 2013, Paul Wise wrote:
> On Fri, May 10, 2013 at 4:33 AM, Russ Allbery wrote:
> 
> > That level of security isn't great, though.  GPG keys are much more secure
> > than that password.  What we would want for equivalent security in a web
> > interface is personal X.509 certificates.
> >
> > I think it would be interesting to have that infrastructure in place, but
> > someone would need to build it (probably with some mechanism to bootstrap
> > GPG keys into X.509 certificates -- and be careful of expiration times and
> > figure out a good way to deal with revocation).
> 
> That mechanism already exists (and supports SSH too):
> http://web.monkeysphere.info/

I don't think that you're speaking of the same thing. I see no information
about "X.509 client certificates" in Monkeysphere. It offers ways to
validate the server certificate (if it's not signed by known CA) but it
doesn't seem to offer any solution to manage client certificate.

That said, we already have http://sso.debian.org
(http://wiki.debian.org/DebianSingleSignOn) that we should aim to leverage
for authentication. And if it's not secure enough (and IIRC DSA doesn't
want people to use this SSO for sensitive operations), then that's the
single point where we should improve our infrastructure.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

-- 
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/20130510061621.ga16...@x230-buxy.home.ouaza.com

Re: Developer repositories for Debian