Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC as Init System for Debian]

2012-05-11 Thread Gergely Nagy
Don Armstrong d...@debian.org writes:

 On Thu, 10 May 2012, Gergely Nagy wrote:
 FWIW, /etc/default/* and /etc/$package/conf.d/* and similar already
 do something *very* close to what etc-overrides-non-etc does. To the
 point that changing a file under /etc/default, or adding a snippet
 to conf.d/ can break just as well when the underlying default
 changes as if that upstream happened to be outside of /etc.

 That's true. I suspect that much of conf.d/* and default/* are a
 consequence of the lack of easy 3-way merge support in dpkg. But
 that's kind of an orthogonal issue.

I don't think that is so. It's also there to allow other packages to
drop snippets there. Modifying another package's conffile would be
against the policy, so conf.d/-style snippets are the obvious solution.

Nothing to do with the lack of merge in this case. Even if dpkg gains
fabulous merge support that never fails, ever, conf.d/ will still be
used because we need the ability to add snippets from unrelated
packages.

 Except it's easier to follow, since the default is never modified
 by the admin, while if it's in /etc too, like in plenty of cases in
 the archive, both can change, and we end up with even scarier
 situations that can't be resolved sanely.

 I'm unable to follow. In the etc-overrides-non-etc case, we would be
 increasing the number of cases where we had copies in /etc and in
 non-etc.

 If things were just in /etc, they wouldn't be in non-etc, and you'd
 only have one copy in all cases.

True, if the non-etc stuff were simply copied, we'd have a single
copy. With all the disadvantages that brings, like not being able to
override the default from another package, as that would mean we have to
modify a configuration file.

In the case of systemd, you need to be able to override the default from
another, unrelated package. At least for things like the syslog
service.

At the moment, systemd has /lib/systemd/system/syslog.service, which
starts the journal. If I want to override that, I need to override the
syslog.service, which is done by placing a file in
/etc/systemd/system/syslog.service (whether a symlink, or a file,
doesn't matter; the syslog daemons in debian place a symlink).

If we didn't have etc-overrides-lib, how would you do this? How would
you make it able to override a single service, from another package?
Play dpkg-divert tricks? Or use conf.d/-style stuff?

The latter suffers from the same issue etc-overrides-non-etc suffers
from, the former makes it much harder for admins to override services,
and I don't like the idea of dpkg-divert'ing config files all over the
place either..

-- 
|8]


-- 
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/873977s1lq@luthien.mhp



Re: mass bug filing: debcheckout fails

2012-05-11 Thread jaalto
On 2012-04-24 18:22, Ansgar Burchardt wrote:
|
| I noticed you started to file bugs for non-working debcheckouts.  Was
| this discussed anywhere as suggested by the developer's reference[1]?

Hi Ansgar,

There are only handful of packages that mistakenly have their Vcs-*
headers set up incorrectly so a minor bug reports and corrective
instructions were sent. In this regard I dind't consider it worthy of
mass bug filing process although it may have been in place.

| imagine a new lintian check could also achieve.

Correct. The problem is that Lintian's returned severity level does
not adequately correspond to the problem level this error is
causing. Many package maintainers don't even see the Lintian warnings
if they don't crank up the reporting levels. I've asked Lintian
maintainer to reconsider the severity of the Vcs header check.

This particular case directly affects usability because every
debcheckout command fails for all non-members that don't have
development access to Vcs repositories.

A minor bug report serves as a reminder to make maintainers aware of
the problem and to consider including a fix in future uploads.

Jari

| [1] 
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#submit-many-bugs


-- 
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/20120511055436.gi13...@taiko.cante.net



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Tollef Fog Heen
]] Uoti Urpala 

Hi,

 Wrong: as mentioned in this thread before, one of the advantages of the
 etc-overrides-lib model is the option of having a file in /etc that
 first includes the one in /lib, then overrides just one particular
 value. This allows handling more updates without needing manual changes,
 as you can automatically pick up other updated values while keeping the
 override, without needing to do 3-way merges.

This doesn't always work, though.  For instance, for systemd, you'd have
no way to get rid of an ExecStartPre line, since you can have multiple
of them.  It's probably not that common, but it's a use case I want to
support.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vck3ns91@qurzaw.varnish-software.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Vincent Bernat
OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait :

 I do not know about trivially merging changes in the etc-overrides-lib
 model, but in the current model, I am presented with the dpkg prompt
 about conffiles for some programs where I added (or changed) only one
 line (off the top of my head: only the servers list in roundcube, for
 example), and dpkg does not propose to merge the two files: I am either
 stuck with keeping my old file, taking the new, or using a shell. All
 these things are interactive and prevent unattended upgrades without
 disruption of services.

roundcube uses  ucf for its  main configuration file and  therefore, you
should have a prompt with possibility to merge.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

printk(KERN_WARNING %s: Short circuit detected on the lobe\n,
dev-name);
2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c


pgputTalXJ2N9.pgp
Description: PGP signature


Re: Directory /boot/console-setup

2012-05-11 Thread Tollef Fog Heen
]] Steve Langasek 

 My complaint is that this is excessively ugly.  For persistent variable data
 that needs to be available during early boot, even when this is binary data
 that the user won't edit, /etc is the normal place to keep it - it's the
 creation of a a .cache subdirectory that I object to.

Very strongly agreed, if we could outright ban using dot directories in
packages for anything packaged (except dotfiles in people's ~, which
should generally not be something that the packaging cares about), I
think that would be a good idea.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r4urnqk2@qurzaw.varnish-software.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marco d'Itri
On May 11, Nikolaus Rath nikol...@rath.org wrote:

  Wrong: since you have to copy the whole file to override it, and files 
  in /lib have no conffiles handling, after an upgrade you will not know 
  what was changed by you and what was changed upstream.
 I think everyone here agrees with that. The interesting case is when
 files in /etc/ can either explicitly include the /lib file, or
 implicitly override the /lib settings.
I do not know about any package which work this way, but there is any 
then the problem is not different from packages which support multiple 
configuration file fragments in /etc, ship the default configuration 
in /etc and allow it to be modified by other configuration fragments in 
/etc (e.g. Apache).

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Philip Hands
On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi wrote:
 Marco d'Itri wrote:
  On May 10, Bjørn Mork bj...@mork.no wrote:
  
   Agree.  Copying a large set of default policies into /etc just because
   they *can* be overridden is not user friendly.  And it does not make the
   defaults any more configuration either. It just hides important local
   changes and makes it difficult both for the user and the application
   itself to distinguish between defaults and configuration overrides.
 
  Wrong:
 
 You're not addressing what he said about the generally desirable /etc
 semantics at all, only talking about what current Debian tools would do
 without modifications. Do you have a reason to oppose beyond this would
 need some tool changes?

Yes -- it scatters configuration state outside /etc (thus hiding it from
etckeeper and sysadmins alike), it makes the packages surprising to
people familiar with Debian but not familiar with the package (Hint: we
have a _lot_ of packages -- nobody is familiar with all of
them. Requiring people to become familiar with all the packages before
they can safely do an upgrade is part of what explains the number of
rotting RedHat systems I see than nobody is brave enough to upgrade).

   since you have to copy the whole file to override it,
 
 Wrong: as mentioned in this thread before, one of the advantages of the
 etc-overrides-lib model is the option of having a file in /etc that
 first includes the one in /lib, then overrides just one particular
 value. This allows handling more updates without needing manual changes,
 as you can automatically pick up other updated values while keeping the
 override, without needing to do 3-way merges.

This is the real problem with the etc-overrides-lib approach.  For a
sysadmin to know what to expect from a particular set of configuration
files they need to be intimately familiar with the package in question,
and why the change was made.  Does the package allow partial overrides
with includes or otherwise?  Is the existence of an empty file deeply
significant (think the udev persistent net thing).  Did some default
appear in lib that needs to be carried into etc? etc. etc.

The traditional Debian approach to /etc is largely self documenting, to
the extent that one can generally walk into a site cold and (having
established that they have decent backups) cheerfully do an upgrade on
their Debian servers without anything breaking (I do this regularly).

The sources of potential breakage are highlighted by the packaging
system, at which point you can read up on any package that needs
attention with which you're not already familiar, while ignoring the
ones that upgrade cleanly.

Having exceptions to that is deeply unhelpful, and the more exceptions
we accumulate the less maintainable and upgradable Debian becomes.

Your assert that etc-overrides-lib is technically superior -- I and many
others dispute that, but even if it were true, using that as a
justification is equivalent to pointing out that driving on the left is
safer[1] so Norway should make arrangements to allow visitors from the
UK to drive on the left while the rest of the country continues on the
right.  When it's pointed out that that's a disastrous idea you respond
by saying that all we need to do is fit some clever (as yet unbuilt)
collision avoidance system to all the roads.

  Obviously this is not a problem for Red Hat since they do not support 
  upgrades between major releases.
 
 Why would this cause problems for Debian, except at most needing some
 changes to tools to better support this case? Or do you think
 implementing that would be hard?

Are you volunteering to do that?

If not then stop making assertions that simply require someone else to
do a load of work to pander to your unusual tastes.  If you are
volunteering, then that's somewhat better (although I would prefer
that we simply fix the packages to behave themselves in a proper Debian
way instead).

Cheers, Phil.

[1] see: 
https://en.wikipedia.org/wiki/Right-_and_left-hand_traffic#Safety_factors
  I believe Japan also did tests -- I don't really care if you disagree,
  just swap Left/Right and UK/Norway throughout the example and relax.
-- 
|)|  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


pgp9a7nnyxdyw.pgp
Description: PGP signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 12:53 AM, Uoti Urpala wrote:
 The reason why most old applications do not follow that approach (at
 least not yet) is pretty obvious: their authors never considered it.
 etc-overrides-lib semantics have only become a seriously considered
 alternative fairly recently.
   
No.

The reason is that we have FHS and the policy, so that packages
*have* to behave the same way, and for very valid reasons which have
been well described in this thread.

You have absolutely everyone (this includes very experienced DDs)
against your idea of changing a well established Debian policy, well
written in the debian policy manual. Please stop. It's going nowhere.

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/4faccc7d.3010...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 04:04 AM, David Weinehall wrote:
 On Fri, May 11, 2012 at 02:44:45AM +0800, Thomas Goirand wrote:
   
 On 05/10/2012 04:52 AM, Steve McIntyre wrote:
 
 No, really - please *do* do this. The fact that a lot of the software
 coming out of RedHat development seems to be designed solely for their
 use, including working around the missing/broken features of RPM, is
 seriously annoying. Configuration belongs in /etc, we know this. We
 have a well-designed and implemented set of tools in Debian based on
 that standard.
   
   
 I agree 100% with the above.

 On 05/10/2012 05:22 AM, Uoti Urpala wrote:
 
 Josh Triplett provided multiple technical reasons why etc-overrides-lib
 is preferable. The ONLY technical reason you gave to prefer traditional
 conffiles was that there already is a set of tools for that in Debian.
   
   
 No, it's because this way, I am warned by the package manager of a change
 on the default file, and I can merge by hand when I see it. Otherwise, you
 are silently changing the default, and potentially, I will miss the new
 options.

 Besides this, configuration files in /etc is written in the stones of
 our bible^Wpolicy-manual.
 
 Has anyone argued for having the configuration files anywhere else?
 It's all in the semantics of course, but to me, the configuration files
 are the files that the administrator changes to change a configuration.
 The files that go in /lib are the defaults.  If the admin wants to
 override something they do so in /etc, just like before.
   

From: http://en.wikipedia.org/wiki/Configuration_file

In computing, configuration files, or config files configure the initial
settings for some computer programs. They are used for user applications,
server processes and operating system settings.

The fact that these files are in /lib and shouldn't be touched by the admin
doesn't make them less configuration files. They still match the above
definition from Wikipedia.

 If the old file in /lib isn't equal to the new file being installed to
 /lib, and there's a user supplied file in /etc rather than just the
 default (which would only include the version in lib), then prompt the
 user.  If the user is running a non-interactive upgrade, fire off an
 e-mail or something.  For any major changes to the /lib files (stuff
 that are likely to trigger user actions), NEWS.Debian should of course,
 as usual, contain a heads up.
   

No need to explain again, again and again the same thing. We did understand
what your point is, but still, we don't agree with you and Uoti. Move on.

 Just because something isn't supported currently in our tools doesn't
 make it impossible to support it.

The very reason why our tools don't support it, is because *we don't
want it*.
It's designed like this on purpose, and we are happy with the way things are
right now.

Why can't you implement something like amavis, grub2, or apache are doing?
Especially Amavis, where the default config is a conffile, but you can
override
what you need by using a higher number in the file name.

It works well, it is integrated with Debian and the way things work...

 And debian-policy isn't set in stone.
 Otherwise it wouldn't have last been revised in February 2012 :)
   

The debian-policy maybe, but the FHS, and config files in /etc *is* a very
strong policy that you will not change in Debian, and for very valid
reasons already described in this thread.

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



Re: etc-overrides-non-etc configuration file model [Re: RFC: OpenRC asInit System for Debian]

2012-05-11 Thread Thomas Goirand
On 05/11/2012 04:21 AM, Uoti Urpala wrote:
 Advantages I mentioned earlier would still be there:
 It's easier to see what is local non-default configuration. Original
 default file is always available in a known location (and very easy to
 revert to, temporarily for testing or permanently).
As I wrote to you *already*, the place where to put such
default configuration to keep it from being overwritten
is /usr/share/doc/$package/examples.

Many packages are doing this, for example:
/usr/share/php5/php.ini-production (which is the exact same
file as /etc/php5/apache/apache2/php.ini).

I'm ok with discussing things, but you are repeating
yourself, and forcing others to do the same. That's
annoying and not moving to the right direction.

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/4facd2ce.1070...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 12:53 AM, Uoti Urpala wrote:
 The reason why most old applications do not follow that approach (at
 least not yet) is pretty obvious: their authors never considered it.
 etc-overrides-lib semantics have only become a seriously considered
 alternative fairly recently.
   
 No.

 The reason is that we have FHS and the policy, so that packages
 *have* to behave the same way, and for very valid reasons which have
 been well described in this thread.

Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.

The stuff in /lib are package defaults. Where the default is, in the
program, embedded, or in some file, doesn't really matter, it's an
implementation detail.

Overrides (ie, configuration) *is* in /etc, as mandated by policy.

 You have absolutely everyone (this includes very experienced DDs)
 against your idea of changing a well established Debian policy, well
 written in the debian policy manual. Please stop. It's going nowhere.

Erm, no. It's not written in the debian policy for a start, and not
everyone agrees that etc-overrides-lib is a bad idea. I for one think
it's a good idea in selected cases (systemd being one such), and no
worse - in some ways, even better - than some other existing practice
(the conf.d/ stuff I mentioned a few times elsewhere in this thread
already).

-- 
|8]


-- 
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/87wr4jumk6.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Tollef Fog Heen tfh...@err.no writes:

 ]] Uoti Urpala 

 Hi,

 Wrong: as mentioned in this thread before, one of the advantages of the
 etc-overrides-lib model is the option of having a file in /etc that
 first includes the one in /lib, then overrides just one particular
 value. This allows handling more updates without needing manual changes,
 as you can automatically pick up other updated values while keeping the
 override, without needing to do 3-way merges.

 This doesn't always work, though.  For instance, for systemd, you'd have
 no way to get rid of an ExecStartPre line, since you can have multiple
 of them.  It's probably not that common, but it's a use case I want to
 support.

In that case, the including file can be changed (by the admin) to be a
separate file, that does not include, and get the usual conffile
conflict dpkg prompt.

-- 
|8]


-- 
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/87sjf7umhf.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Philip Hands p...@hands.com writes:

 On Thu, 10 May 2012 21:30:56 +0300, Uoti Urpala uoti.urp...@pp1.inet.fi 
 wrote:
 Marco d'Itri wrote:
  On May 10, Bjørn Mork bj...@mork.no wrote:
  
   Agree.  Copying a large set of default policies into /etc just because
   they *can* be overridden is not user friendly.  And it does not make the
   defaults any more configuration either. It just hides important local
   changes and makes it difficult both for the user and the application
   itself to distinguish between defaults and configuration overrides.
 
  Wrong:
 
 You're not addressing what he said about the generally desirable /etc
 semantics at all, only talking about what current Debian tools would do
 without modifications. Do you have a reason to oppose beyond this would
 need some tool changes?

 Yes -- it scatters configuration state outside /etc (thus hiding it from
 etckeeper and sysadmins alike), it makes the packages surprising to
 people familiar with Debian but not familiar with the package (Hint: we
 have a _lot_ of packages -- nobody is familiar with all of
 them. Requiring people to become familiar with all the packages before
 they can safely do an upgrade is part of what explains the number of
 rotting RedHat systems I see than nobody is brave enough to upgrade).

I'll turn this around: how do you handle cases where the defaults of
packages like apt, exim or syslogd change? Where the defaults are
embedded in the executable.

You don't. That systemd has the defaults in files under /lib is an
implementation detail. It's no different than any other default other
software comes with, except that this one is easier to see and notice
when it changes: it's possible to craft a trigger that'd fire in those
cases.

It's not possible to do that for cases where the default is hidden,
which is the case for the vast majority of software. Yet, I do not see
anyone jumping on those, and demanding they move *all* their defaults to
/etc.

   since you have to copy the whole file to override it,
 
 Wrong: as mentioned in this thread before, one of the advantages of the
 etc-overrides-lib model is the option of having a file in /etc that
 first includes the one in /lib, then overrides just one particular
 value. This allows handling more updates without needing manual changes,
 as you can automatically pick up other updated values while keeping the
 override, without needing to do 3-way merges.

 This is the real problem with the etc-overrides-lib approach.  For a
 sysadmin to know what to expect from a particular set of configuration
 files they need to be intimately familiar with the package in question,
 and why the change was made.  Does the package allow partial overrides
 with includes or otherwise?  Is the existence of an empty file deeply
 significant (think the udev persistent net thing).  Did some default
 appear in lib that needs to be carried into etc? etc. etc.

The same could be said of various conf.d/-style hacks that plague the
archive. Do snippets override the things they change, or do they get
merged? One must be familiar with the particular program to figure it
out.

This problem exists in every piece of software that can be configured,
and does not use a single monolithic configuration file.

 The traditional Debian approach to /etc is largely self documenting, to
 the extent that one can generally walk into a site cold and (having
 established that they have decent backups) cheerfully do an upgrade on
 their Debian servers without anything breaking (I do this regularly).

I'm afraid my experience disagrees, see above: the conf.d/-style hacks
vary between packages, and there is *no* common ground. Some override
settings completely, some get merged, it largely depends not only on the
package in question, but in the setting aswell: even within a package,
some settings get merged, some get overwritten.

Sometimes it is even an error to try and override parts of the main
configuration within a snippet - and you can't tell that only by looking
at the files. You have to know the software in question, and how its
configuration works.

etc-over-lib is no different to existing practice. The only difference
is where the defaults live, nothing else.

 The sources of potential breakage are highlighted by the packaging
 system, at which point you can read up on any package that needs
 attention with which you're not already familiar, while ignoring the
 ones that upgrade cleanly.

Like I said elsewhere in the thread: conf.d/-style snippets. They're
widely used, show the same problems. etc-over-lib is no worse.

 Having exceptions to that is deeply unhelpful, and the more exceptions
 we accumulate the less maintainable and upgradable Debian becomes.

etc-over-lib is no exception. It's configuration in /etc, that overrides
or changes default. Like *every* other piece of configuration that is in
/etc. Where the default is, doesn't matter.

We *never* get notification when defaults change, unless the default 

Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Tollef Fog Heen
]] Gergely Nagy 

 Tollef Fog Heen tfh...@err.no writes:
 
  ]] Uoti Urpala 
 
  Hi,
 
  Wrong: as mentioned in this thread before, one of the advantages of the
  etc-overrides-lib model is the option of having a file in /etc that
  first includes the one in /lib, then overrides just one particular
  value. This allows handling more updates without needing manual changes,
  as you can automatically pick up other updated values while keeping the
  override, without needing to do 3-way merges.
 
  This doesn't always work, though.  For instance, for systemd, you'd have
  no way to get rid of an ExecStartPre line, since you can have multiple
  of them.  It's probably not that common, but it's a use case I want to
  support.
 
 In that case, the including file can be changed (by the admin) to be a
 separate file, that does not include, and get the usual conffile
 conflict dpkg prompt.

How would that work?

I have /lib/systemd/system/foo.service and want to change something in
it, I then create /etc/systemd/system/foo.service with a copy of the
/lib one plus whatever changes I want.

The version in /lib is then updated.  How is the admin notified?

(This is the problem I want to fix with some yet unwritten tool.)

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k40jnjmv@qurzaw.varnish-software.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 From: http://en.wikipedia.org/wiki/Configuration_file

 In computing, configuration files, or config files configure the initial
 settings for some computer programs. They are used for user applications,
 server processes and operating system settings.

 The fact that these files are in /lib and shouldn't be touched by the admin
 doesn't make them less configuration files. They still match the above
 definition from Wikipedia.

Can I point you to /usr/share/glib-2.0/schemas/,
/usr/share/gconf/defaults and similar?

These are by the above definition, configuration files. Yet they are not
under /etc. They are used to load the initial configuration of software,
and can be overridden elsewhere (funny thing is, the gconf defaults can
be overridden with stuff in /var/lib/gconf/debian.* - even the overides
are outside of /etc!).

Can we fix these first, where not even the overrides are in /etc, let
alone the defaults? Please?

 Just because something isn't supported currently in our tools doesn't
 make it impossible to support it.

 The very reason why our tools don't support it, is because *we don't
 want it*.
 It's designed like this on purpose, and we are happy with the way things are
 right now.

Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, without any kind of default anywhere else.

 Why can't you implement something like amavis, grub2, or apache are doing?
 Especially Amavis, where the default config is a conffile, but you can
 override
 what you need by using a higher number in the file name.

 It works well, it is integrated with Debian and the way things work...

It certainly does not work all that well. We came to live with it over
the years, is all.

 And debian-policy isn't set in stone.
 Otherwise it wouldn't have last been revised in February 2012 :)
   

 The debian-policy maybe, but the FHS, and config files in /etc *is* a very
 strong policy that you will not change in Debian, and for very valid
 reasons already described in this thread.

And in etc-overrides-lib, config files still remain in /etc. Its just
the defaults that live elsewhere. That the defaults are files, and are
under /lib, is an implementation detail, similarly how gconf defaults
live under /usr/share/gconf/defaults.

FHS and Policy are obeyed.

-- 
|8]


-- 
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/87bolvul1l.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marco d'Itri
On May 11, Gergely Nagy alger...@balabit.hu wrote:

 And in etc-overrides-lib, config files still remain in /etc. Its just
 the defaults that live elsewhere. That the defaults are files, and are
 under /lib, is an implementation detail, similarly how gconf defaults
 live under /usr/share/gconf/defaults.
This is not similar to how gconf works, because gconf allows you to only 
set the directives you need in the new file, while udev and systemd 
require copying the whole file from /lib.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Stephan Seitz

On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:

Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.


To be honest, I still don’t really understand what the files in lib are:

- Are they configuration examples with all possible settings and their 
  default values and the application works fine without these files? Then 
  they should be in /usr/share/doc/package.
- Or doesn’t the application start without these files? Then they are 
  undoubtedly configuration files and according to FHS and Debian policy 
  configuration files belong in /etc



The stuff in /lib are package defaults. Where the default is, in the
program, embedded, or in some file, doesn't really matter, it's an
implementation detail.


It does matter. In the end it is the same situation as the firmware 
problem. For the hardware it doesn’t matter if the firmware is placed in 
an EEPROM on the hardware or loaded from the FS by the driver. But for 
Debian and its policy it is a difference.
So if you don’t want a default configuration from a file, because you 
don’t want to put a file in /etc, then you must compile the program with 
your default settings.



worse - in some ways, even better - than some other existing practice
(the conf.d/ stuff I mentioned a few times elsewhere in this thread
already).


I like conf.d. It makes things easier for e.g. rsyslog or sysctl.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Stephan Seitz

On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:

Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, without any kind of default anywhere else.


Yes, because I know that something is wrong when it breaks. This is 
better than the software is working but not anymore as you expect.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Tollef Fog Heen tfh...@err.no writes:

 ]] Gergely Nagy 

 Tollef Fog Heen tfh...@err.no writes:
 
  ]] Uoti Urpala 
 
  Hi,
 
  Wrong: as mentioned in this thread before, one of the advantages of the
  etc-overrides-lib model is the option of having a file in /etc that
  first includes the one in /lib, then overrides just one particular
  value. This allows handling more updates without needing manual changes,
  as you can automatically pick up other updated values while keeping the
  override, without needing to do 3-way merges.
 
  This doesn't always work, though.  For instance, for systemd, you'd have
  no way to get rid of an ExecStartPre line, since you can have multiple
  of them.  It's probably not that common, but it's a use case I want to
  support.
 
 In that case, the including file can be changed (by the admin) to be a
 separate file, that does not include, and get the usual conffile
 conflict dpkg prompt.

 How would that work?

 I have /lib/systemd/system/foo.service and want to change something in
 it, I then create /etc/systemd/system/foo.service with a copy of the
 /lib one plus whatever changes I want.

 The version in /lib is then updated.  How is the admin notified?

NEWS.Debian, like with any significant default change.

Other than that, the best I can think of is keeping track of what
version of the package a default changed in, and triggering something
from preinst, when upgrading from a version that is older than the
change.

This however, requires a lot of manual work, might aswell shovel the
whole thing from under /lib to /etc then, but then we still didn't solve
the problem: suppose there is a unit file that supports starting
multiple instances, by way of symlinking. I start to use this feature,
I change nothing, just symlink files around. At some point, this feature
gets removed, my upgrade succeeds, but my instances won't start anymore,
and the best notification I have is something that scrolled by that a
conffile was upgraded.

In this case, we have a succesful upgrade resulting in a broken system,
because a default changed, and the user was not adequately notified.

Which gets us back to NEWS.Debian being the best solution. There simply
are cases where no automatism can be clever enough.

-- 
|8]


-- 
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/877gwjujxr.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Jean-Christophe Dubacq
On 11/05/2012 08:47, Vincent Bernat wrote:
 OoO  Pendant le  journal  télévisé du  jeudi  10 mai  2012, vers  20:29,
 Jean-Christophe Dubacq jean-christophe.dub...@ens-lyon.org disait :
 
 I do not know about trivially merging changes in the etc-overrides-lib
 model, but in the current model, I am presented with the dpkg prompt
 about conffiles for some programs where I added (or changed) only one
 line (off the top of my head: only the servers list in roundcube, for
 example), and dpkg does not propose to merge the two files: I am either
 stuck with keeping my old file, taking the new, or using a shell. All
 these things are interactive and prevent unattended upgrades without
 disruption of services.
 
 roundcube uses  ucf for its  main configuration file and  therefore, you
 should have a prompt with possibility to merge.
Never got it. But I can quote other (courier, for example).
Even /etc/default/locale was updated (only to include a bunch of
comments). Is it really necessary ?

BTW, for standard workstations, there is less and less need to change
things in /etc. My current quota is 1346 files in /etc for about 30 of
them with local changes. This is quite a bad signal/noise ratio.

If dpkg kept a copy of the original configuration file (to be retrieved
at all times), it would be easier to spot local changes.
I use etckeeper to do that, but it's a bit tiresome to isolate all local
changes (I have to save the diffs somewhere) (and a lost hope if you do
install etckeeper late in the workstation life). My  git-fu is probably
not good enough (I am probably looking for a pristine branch and a
rebased local branch used in production).
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Stephan Seitz

On Fri, May 11, 2012 at 12:07:55PM +0200, Jean-Christophe Dubacq wrote:

BTW, for standard workstations, there is less and less need to change
things in /etc. My current quota is 1346 files in /etc for about 30 of
them with local changes. This is quite a bad signal/noise ratio.


Well, a standard workstation has many configuration changes I would say, 
but these changes are all user settings for their WM/DM or application 
configuration like pidgin or audacious that reside in /home/user.


But if you don’t configure files in /etc, why is it a problem if you have 
many files in /etc?


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Stephan Seitz stse+deb...@fsing.rootsland.net writes:

 On Fri, May 11, 2012 at 11:25:10AM +0200, Gergely Nagy wrote:
Are you happy with dropping a snippet into a conf.d/ directory, and your
software breaking on an upgrade without notice? Because that can happen
even now, with software that uses only /etc, and /etc alone for their
configuration, without any kind of default anywhere else.

 Yes, because I know that something is wrong when it breaks. This is
 better than the software is working but not anymore as you expect.

You do realize that the only difference between the two cases is that
when the default happens to be in /etc, you get a Configuration file
updated thing scroll by?

Other than that, things break exactly the same way, and you will have no
more information, and the one you have is of little use, as it happily
overwrote the unmodified default, so you'll have to hunt down the former
version anyway, to see the difference.

-- 
|8]


-- 
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/87vck3t483.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Steve McIntyre
Jean-Christophe Dubacq wrote:

If dpkg kept a copy of the original configuration file (to be retrieved
at all times), it would be easier to spot local changes.
I use etckeeper to do that, but it's a bit tiresome to isolate all local
changes (I have to save the diffs somewhere) (and a lost hope if you do
install etckeeper late in the workstation life). My  git-fu is probably
not good enough (I am probably looking for a pristine branch and a
rebased local branch used in production).

You might be interested in a proposal at UDS this week:

https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You can't barbecue lettuce! -- Ellie Crane


-- 
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/e1ssnta-0007af...@mail.einval.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
m...@linux.it (Marco d'Itri) writes:

 On May 11, Gergely Nagy alger...@balabit.hu wrote:

 And in etc-overrides-lib, config files still remain in /etc. Its just
 the defaults that live elsewhere. That the defaults are files, and are
 under /lib, is an implementation detail, similarly how gconf defaults
 live under /usr/share/gconf/defaults.
 This is not similar to how gconf works, because gconf allows you to only 
 set the directives you need in the new file, while udev and systemd 
 require copying the whole file from /lib.

But by the wikipedia definition, the gconf defaults are config files
too. My point was to make it clear that blindly following that
definition might not lead to desirable results.

But, a few more examples of config files, or snippets from directories
different than /etc:

 * /usr/share/X11/xorg.conf.d/: I would especially like to quote these
   lines from the 50-synaptics.conf file from there:

   ,
   | # DO NOT EDIT THIS FILE, your distribution will likely overwrite
   | # it when updating. Copy (and rename) this file into
   | # /etc/X11/xorg.conf.d first.
   `

   While said file also says it is an example, looking at
   xorg.conf.d(5), it suggests that X11 will behave somewhat similar to
   systemd, and search for override-able config snippets in directories
   outside of /etc. According to the manpage:

When the same information is supplied in more than one way, the
highest precedence mechanism is used.

   In other words, it does *exactly* the same thing systemd is
   criticised for.

 * /usr/share/alsa/alsa.conf.d/: Files herein will be processed by
   alsa-lib, according to the README. They are obviously config file
   snippets, and as such, if following the wikipedia definition, should
   be in /etc.

   I assume - though, haven't checked - that files in /etc can override
   these settings.

I could probably find more, but just two off the top of my /usr/share
seemed enough for now.

It seems to me that etc-overrides-non-etc is already existing practice,
if X11 and ALSA use it too, among others. In light of this, systemd is
no different. It just has more defaults in files under /lib.

Long story short, I still don't see what the fuss is about.

-- 
|8]


-- 
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/87obpvt313.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Stephan Seitz stse+deb...@fsing.rootsland.net writes:

 On Fri, May 11, 2012 at 10:52:25AM +0200, Gergely Nagy wrote:
Neither the FHS, nor the policy says anything about etc-overrides-lib as
far as I can see. Neither pro or con. Do feel free to point me to the
relevant section, would I be mistaken.

 To be honest, I still don’t really understand what the files in lib are:

 - Are they configuration examples with all possible settings and their
 default values and the application works fine without these files?
 Then they should be in /usr/share/doc/package.

They are default settings for a particular service, and the application
does not work without them.

 - Or doesn’t the application start without these files? Then they are
 undoubtedly configuration files and according to FHS and Debian policy
 configuration files belong in /etc

It is indeed true, that these are settings the application does not work
without. So are many things under /usr/share, some of them similarly
configuration files (/usr/share/X11/xorg.conf.d/;
/usr/share/alsa/alsa.conf.d/ to name just two).

That a default happens to be in a file does not make it a configuration
file. A configuration file is something you *change* to alter a programs
behaviour.

With systemd, these files are under /etc. That the defaults are split
out into separate files is an implementation detail, nothing more. You
do *NOT* change the defaults. You change the settings.

The stuff in /lib are package defaults. Where the default is, in the
program, embedded, or in some file, doesn't really matter, it's an
implementation detail.

 It does matter. In the end it is the same situation as the firmware
 problem. For the hardware it doesn’t matter if the firmware is placed
 in an EEPROM on the hardware or loaded from the FS by the driver. But
 for Debian and its policy it is a difference.

Policy governs configuration. It never talks about default settings, it
does not mandate anywhere where and how defaults are to be set.

 So if you don’t want a default configuration from a file, because you
 don’t want to put a file in /etc, then you must compile the program
 with your default settings.

What happens if your defaults are open-ended? When you *can't* compile
them all in, because third party packages are able to extend the set of
default settings?

You can't compile in the defaults in that case. You could compile in the
subset shipped with the package, and you could make it so that third
party packages only use stuff in /etc, but that would needlessly
complicate matters for no real benefit.

worse - in some ways, even better - than some other existing practice
(the conf.d/ stuff I mentioned a few times elsewhere in this thread
already).

 I like conf.d. It makes things easier for e.g. rsyslog or sysctl.

They also suffer from the very same problem the defaults in /lib/systemd
do. Namely, if you did not change the default, and it changes under you,
your system can break without any kind of warning or notice, and very
little trace as to what went wrong.

-- 
|8]


--
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/87k40jt2l2.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 04:52 PM, Gergely Nagy wrote:
 Neither the FHS, nor the policy says anything about etc-overrides-lib as
 far as I can see. Neither pro or con. Do feel free to point me to the
 relevant section, would I be mistaken.
   

Section 10.7.2 of dpm:

Any configuration files created or used by your package must reside in
|/etc|.

The policy never talks about etc-overrides-lib configuration files, it
only tells
that all configuration files should go in /etc, and there's no
exception, and
it is also a must.

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/4facf2d8.5050...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 05:25 PM, Gergely Nagy wrote:
 And in etc-overrides-lib, config files still remain in /etc.
No.


-- 
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/4facf398.2010...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
In other words, it does *exactly* the same thing systemd is
criticised for.
   

Which doesn't mean that it's a good practice.

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/4facf423.1090...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 06:39 PM, Gergely Nagy wrote:
 Long story short, I still don't see what the fuss is about.
   
The fuss is about we're being told that there will be silent
overwriting of configuration files without being prompted about
changes, which potentially, will make it horrible to manage
upgrades in a decent way without knowing the corner cases.

On top of that, we're being told that this is the reason why
we should use this system, which is totally the inverse of
what we've been doing in Debian for years.

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/4facf4fd.8000...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Steve McIntyre st...@einval.com writes:

 Jean-Christophe Dubacq wrote:

If dpkg kept a copy of the original configuration file (to be retrieved
at all times), it would be easier to spot local changes.
I use etckeeper to do that, but it's a bit tiresome to isolate all local
changes (I have to save the diffs somewhere) (and a lost hope if you do
install etckeeper late in the workstation life). My  git-fu is probably
not good enough (I am probably looking for a pristine branch and a
rebased local branch used in production).

 You might be interested in a proposal at UDS this week:

 https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

So basically, we'd have a directory of files under /etc that are not
conffiles, and even made 0440. Amusing proposal.

Why not move them outside of /etc then, if they are not configuration
files, and should not be touched by the user?

(Yeah, sure, they can be moved out of /etc, but that doesn't stop the
original proposal being amusing, sorry.)

-- 
|8]


-- 
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/87fwb7t1vo.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 04:52 PM, Gergely Nagy wrote:
 Neither the FHS, nor the policy says anything about etc-overrides-lib as
 far as I can see. Neither pro or con. Do feel free to point me to the
 relevant section, would I be mistaken.
   

 Section 10.7.2 of dpm:

 Any configuration files created or used by your package must reside in
 |/etc|.

 The policy never talks about etc-overrides-lib configuration files, it
 only tells
 that all configuration files should go in /etc, and there's no
 exception, and
 it is also a must.

But these are default settings, not configuration files. The
configuration files *are* in /etc. Configuration files are stuff you
want to change, defaults are things upstream (or at worst, the package
maintainer) decides them to be, and the user has no business touching
them. That is what configuration is for, to change the defaults.

That the defaults happen to be files instead of some compiled in thing,
is an implementation detail.

But be my guest, if you take this seriously, please file a bug against
X11 (see xorg.conf.d(5) for a reason) and other packages that do the
same thing systemd does.

-- 
|8]


-- 
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/87bolvt1f6.fsf@algernon.balabit



Strange bug in Qt program after build with gcc 4.7

2012-05-11 Thread Boris Pek
Hi all,

There is no any reply in debian-mentors mailing list, so I am forwarding my
message here. Please Cc me in replies, I am not subscribed to debian-devel.

 begin original message 
2012-05-10 21:08, Boris Pek wrote:

Hi everyone,

I have strange problem with my package eiskaltdcpp-qt.

When I compile this binary file using gcc 4.6 program works fine.
But when I compile it using gcc 4.7 program crashes at launch time.

Full backtrace from gdb shows that segmentation fault is in Qt library [1].
Bug was also confirmed in Fedora and Arch Linux.

C++11 is actively used in eiskaltdcpp-qt. Could it causes the bug?

I have tried to make minimum reproducible example but without success.

Could anyone look on my package? Any suggestions are welcome.

Package can be found on m.d.n [2][3]. Or you could get sources directly from
upstream [4]. Problem exists in all last releases since 2.2.5 (I have not
checked earlier versions).

Also what mailing list is relevant for such bugs?
Maybe debian-devel or another one?

Best regards,
Boris

PS: I use Debian Sid with all recent updates.

[1] See eiskaltdcpp-qt.gdb.bt_full.log in attachment
[2] http://mentors.debian.net/package/eiskaltdcpp
[3] 
http://mentors.debian.net/debian/pool/main/e/eiskaltdcpp/eiskaltdcpp_2.2.6-4.dsc
[4] https://github.com/negativ/eiskaltdcpp

 end original message 
$ gdb eiskaltdcpp-qt 
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/eiskaltdcpp-qt...done.
(gdb) run
Starting program: /usr/bin/eiskaltdcpp-qt 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1.
Installing handler for: Segmentation fault
Installing handler for: Aborted
Installing handler for: Bus error
Installing handler for: Terminated
Signal handlers installed.
[New Thread 0xb2d09b70 (LWP 2935)]
[New Thread 0xb2508b70 (LWP 2936)]
Loading: Hash database
[New Thread 0xb1bcfb70 (LWP 2937)]
[Thread 0xb2508b70 (LWP 2936) exited]
Loading: Shared Files
[New Thread 0xb2508b70 (LWP 2941)]
Loading: Download Queue
Loading: Users
[New Thread 0xb13ceb70 (LWP 2942)]
UserList icons has been loaded
Application icons has been loaded
[New Thread 0xb0024b70 (LWP 2943)]
[New Thread 0xaf823b70 (LWP 2944)]
[New Thread 0xaf022b70 (LWP 2945)]
[New Thread 0xae821b70 (LWP 2946)]
[New Thread 0xae020b70 (LWP 2947)]

Program received signal SIGSEGV, Segmentation fault.
__strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52
52  ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S: No such file or 
directory.
(gdb) bt full
#0  __strlen_sse2_bsf () at ../sysdeps/i386/i686/multiarch/strlen-sse2-bsf.S:52
No locals.
#1  0xb5c414e5 in XSetCommand () from /usr/lib/i386-linux-gnu/libX11.so.6
No symbol table info available.
#2  0xb5c45ee3 in XSetWMProperties () from /usr/lib/i386-linux-gnu/libX11.so.6
No symbol table info available.
#3  0xb70ab646 in QWidgetPrivate::create_sys(unsigned long, bool, bool) ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#4  0xb705582f in QWidget::create(unsigned long, bool, bool) ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#5  0xb7724c77 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#6  0xb7725a91 in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#7  0xb7725bea in ?? () from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#8  0xb770dac8 in QSystemTrayIcon::setVisible(bool) ()
   from /usr/lib/i386-linux-gnu/libQtGui.so.4
No symbol table info available.
#9  0x0827519a in show (this=optimized out)
at /usr/include/qt4/QtGui/qsystemtrayicon.h:108
No locals.
#10 Notification::enableTray (this=this@entry=0x972dbd0, enable=true)
at ../../eiskaltdcpp-qt/src/Notification.cpp:136
menuAdditional = 0x97836d0
actSupressTxt = 0x8e27838
menu = 0x978fbb0
actSupressSnd = 0x8e29160
show_hide = optimized out
setup_speed_lim = 0x97b1910
close_app = 0x97736d0
sep = 0x8e29fd8
#11 0x08275590 in Notification::Notification (this=0x972dbd0, parent=0x0)
at ../../eiskaltdcpp-qt/src/Notification.cpp:41
No locals.
#12 0x08178fda in dcpp::SingletonNotification::newInstance ()
at ../../dcpp/Singleton.h:47
No locals.
#13 0x080d8bfc in main (argc=1, argv=0xb1a4) at 
../../eiskaltdcpp-qt/src/main.cpp:172
app = {QtSingleCoreApplication = {QApplication = {No data 
fields}, 
static staticMetaObject = {d = 

Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 06:39 PM, Gergely Nagy wrote:
In other words, it does *exactly* the same thing systemd is
criticised for.
   

 Which doesn't mean that it's a good practice.

Tell me what you would gain, if there were no files under /lib/systemd,
and all of these were compiled into the binary, please. Because that's
the other option, as you *do not* let users change the defaults. You let
them override them, you let them configure the system. (And that *is*
being done in /etc.)

There are *very* few programs that come without any kind of default, and
even less, that let you change the default too.

apt does not let you change the defaults, nor does dpkg. Both allow you
to change their settings, but without recompiling, you can't change the
defaults. Same happens with systemd, the difference is that it's easier
to see the defaults, as they're broken out into files that are easy to
copy and change as needed.

-- 
|8]


-- 
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/874nrnt155.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Uoti Urpala
Philip Hands wrote:
 The traditional Debian approach to /etc is largely self documenting, to
 the extent that one can generally walk into a site cold and (having
 established that they have decent backups) cheerfully do an upgrade on
 their Debian servers without anything breaking (I do this regularly).

If you walk into a site cold, how do you tell if they have weird local
configuration for something? It's much easier to check if there's
something under /etc than to start checking whether the files match
what's expected for the package version, if the the default files are
always there even if nothing has been configured.

 The sources of potential breakage are highlighted by the packaging
 system, at which point you can read up on any package that needs
 attention with which you're not already familiar, while ignoring the
 ones that upgrade cleanly.

And why would this have to be any worse with etc-overrides-lib? 


  Why would this cause problems for Debian, except at most needing some
  changes to tools to better support this case? Or do you think
  implementing that would be hard?
 
 Are you volunteering to do that?
 
 If not then stop making assertions that simply require someone else to
 do a load of work to pander to your unusual tastes.  If you are
 volunteering, then that's somewhat better (although I would prefer
 that we simply fix the packages to behave themselves in a proper Debian
 way instead).

No, I'm not volunteering, mainly because I don't want to program in
shell (which ucf seems to be implemented in). I can still estimate what
such an implementation would need to do. You can't argue that everything
which has not already been implemented would be a huge fundamental
problem. If you want to argue that etc-overrides-lib would be
fundamentally bad, hard to support, or undesirable to even try to
support in Debian, then you should say more about implementation
difficulties than just it's not implemented at the moment.

George Danchev gave a proposed implementation of change alerts in an
earlier mail:
http://lists.debian.org/201205110212.30503.danc...@spnet.net

While there are things you'd want to improve in a real implementation
for packager convenience and better user interface (and the ucf part
looks like it'd incorrectly create the file under /etc by default), I
think that's enough to demonstrate this is not a particularly hard
problem.



-- 
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/1336737949.2227.181.camel@glyph.nonexistent.invalid



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread David Weinehall
On Fri, May 11, 2012 at 04:39:22PM +0800, Thomas Goirand wrote:
[snip]
 
 From: http://en.wikipedia.org/wiki/Configuration_file
 
 In computing, configuration files, or config files configure the initial
 settings for some computer programs. They are used for user applications,
 server processes and operating system settings.
 
 The fact that these files are in /lib and shouldn't be touched by the admin
 doesn't make them less configuration files. They still match the above
 definition from Wikipedia.

Since when did Wikipedia have any relevance on Debian?

  If the old file in /lib isn't equal to the new file being installed to
  /lib, and there's a user supplied file in /etc rather than just the
  default (which would only include the version in lib), then prompt the
  user.  If the user is running a non-interactive upgrade, fire off an
  e-mail or something.  For any major changes to the /lib files (stuff
  that are likely to trigger user actions), NEWS.Debian should of course,
  as usual, contain a heads up.

 
 No need to explain again, again and again the same thing. We did understand
 what your point is, but still, we don't agree with you and Uoti. Move on.

Talking about yourself in pluralis majestatis now?

  Just because something isn't supported currently in our tools doesn't
  make it impossible to support it.
 
 The very reason why our tools don't support it, is because *we don't
 want it.  It's designed like this on purpose, and we are happy with
 the way things are right now.

Yes, I get it that you are.  Or are you somehow assuming that you can
speak for all of Debian?  I guess you're aware of the fact that I'm a DD
too?

 Why can't you implement something like amavis, grub2, or apache are
 doing?  Especially Amavis, where the default config is a conffile, but
 you can override what you need by using a higher number in the file
 name.
 
 It works well, it is integrated with Debian and the way things work...

A solution with configuration files in /etc including, or overriding,
defaults elsewhere works well too.  gconf is a good example.

Tollef's example of how to handle the case of a setting that can be set
multiple times is probably needs some thought though, but that
particular case can be solved by copying rather than including, if needs
be.

Anyway, I'm neither systemd maintainer nor upstream, so I don't believe
I'm the right person to speak to.  Then again, neither are you TTBOMK :)

  And debian-policy isn't set in stone.
  Otherwise it wouldn't have last been revised in February 2012 :)

 
 The debian-policy maybe, but the FHS, and config files in /etc *is* a very
 strong policy that you will not change in Debian, and for very valid
 reasons already described in this thread.

Sigh.  The config files remain in /etc.  The defaults are not.  There's
nothing in FHS that contradicts such a behaviour.


Regards: David
-- 
 /) David Weinehall t...@debian.org /) Rime on my window   (\
//  ~   //  Diamond-white roses of fire //
\)  http://www.acc.umu.se/~tao/(/   Beautiful hoar-frost   (/


-- 
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/20120511122856.gg10...@suiko.acc.umu.se



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marco d'Itri
On May 11, Gergely Nagy alger...@balabit.hu wrote:

 Long story short, I still don't see what the fuss is about.
Apparently the reason is that you do not understand the problem, since 
you keep getting back to the not relevant issue of software which 
supports placing configuration directives in multiple directories.
This is not what etc-overrides-lib is about: with udev and systemd, if 
you create a file in /etc then the file with the same name in /lib is 
ignored.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marco d'Itri
On May 11, Thomas Goirand z...@debian.org wrote:

  Long story short, I still don't see what the fuss is about.
 The fuss is about we're being told that there will be silent
 overwriting of configuration files without being prompted about
 changes, which potentially, will make it horrible to manage
 upgrades in a decent way without knowing the corner cases.
No, not even that: if you edit files in /lib without being aware of the 
consequences then you are an idiot and deserve to suffer for it.
The problem with etc-overrides-lib is that a file must be copied in 
full from /lib to /etc to be modified, and then future changes to the 
same file in /lib will be ignored (so maybe the package will break 
because these changes are required, etc).

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Tollef Fog Heen
]] Thomas Goirand 

 On 05/11/2012 06:39 PM, Gergely Nagy wrote:
  Long story short, I still don't see what the fuss is about.

 The fuss is about we're being told that there will be silent
 overwriting of configuration files without being prompted about
 changes, which potentially, will make it horrible to manage
 upgrades in a decent way without knowing the corner cases.

I've not yet seen anybody saying that, so could you provide a reference,
please?  Preferably by somebody who is actually going to be doing some
of the work.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwb6oq1x@qurzaw.varnish-software.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Michael Biebl
Am 11.05.2012 14:30, schrieb Marco d'Itri:
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).

You can either copy the file or use the .include directive (which was
already mentioned) and only override the settings you need.
So systemd provides both semantics and you can chose which one you
want/need.

Michael



signature.asc
Description: OpenPGP digital signature


Bug#672480: ITP: prooftree -- proof tree visualization for Proof General

2012-05-11 Thread Hendrik Tews
Package: wnpp
Owner: Hendrik Tews hend...@askra.de
Severity: wishlist

* Package name: prooftree
  Version : 0.9
  Upstream Author : Hendrik Tews
* URL or Web page : http://askra.de/software/prooftree/
* License : GPL-3
  Description : proof tree visualization for Proof General

 Prooftree draws proof trees during interactive proof development
 with Proof General. One can inspect goals and proof commands
 and check where existential variables were introduced and
 instantiated. Currently, Prooftree does only work for Coq.


Actually Prooftree requires Coq 8.4, which has not been released
yet. There is also work on supporting HOL Light, but this has not
been released either. However, there is a good chance that 
Coq 8.4 and/or the HOL Light support in Proof General will get
included in the next Debian release. Given the time it takes to
get a new package into Debian, it is probably not too early to
start now with packaging Prooftree.

Even if Coq 8.4 and the HOL Light support in Proof General will
not be included in the next Debian release, it would be good to
have Prooftee in the archive. Users would then only need to
install Coq or Proof General manually and could rely on the
Prooftree package.


Bye,

Hendrik



-- 
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/6x3976vqt0@blau.inf.tu-dresden.de



Configuration file handling (was: RFC: OpenRC as Init System for Debian)

2012-05-11 Thread Roger Leigh
On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote:
 Jean-Christophe Dubacq wrote:
 
 If dpkg kept a copy of the original configuration file (to be retrieved
 at all times), it would be easier to spot local changes.
 I use etckeeper to do that, but it's a bit tiresome to isolate all local
 changes (I have to save the diffs somewhere) (and a lost hope if you do
 install etckeeper late in the workstation life). My  git-fu is probably
 not good enough (I am probably looking for a pristine branch and a
 rebased local branch used in production).
 
 You might be interested in a proposal at UDS this week:
 
 https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

I'm unconvinced that this would be workable.  How many programs and
configuration files reference absolute paths under /etc?  Which
wouldn't be overridable using the proposed mechanism.

Is this going to concern itself only with init.d scripts or all
conffiles?  Bind mounting the prinstine copy over the broken copy
is probably the safest way--it keeps all the paths consistent, though
you'd lose /all/ configuration if you bind over the whole /etc rather
than just parts of it.  A unionfs overlay might also be an option, then
the /etc-only files can show through; but all these are still far too
fragile for my liking.

I would much rather we had a more general mechanism of storing the
real configuration files (as opposed to just md5s) by dpkg itself,
which would enable proper merging of admin changes between old and
new conffiles, and perhaps also allow dpkg to implement ucf-like
conffile handling (or remove the need for ucf entirely).  These
could be stored under /var/lib/dpkg/conffiles (for example).  For
the pristine initscripts use case, it would be possible to
mirror a subset under /lib or /etc.  But how often does anyone
make their system unbootable even with the most extreme init
script hacking?  We already have rescue boot CDs etc. to cater for
this eventuality in any case--why introduce a pile of complexity
into the system when it's already redundant?

On a related note...
While we might criticise rpm for its bad conffile handling, dpkg is
itself fairly woeful, and if we change one thing for wheezy+1, it
should be sane conffile handling.  dpkg should never forget about
conffiles; the fact that maintainer scripts have to take care of
purging such files is a glaring defect, and possibly the source of
the greatest fragility in our maintainer scripts--it's impossible for
maintainer scripts to get this right all the time given all the
corner cases like downgrades and being taken over by other packages.
If this was implemented robustly, the maintainer script should never
need to concern itself with such cleanup, or indeed any manual work
with conffiles at all, except maybe for deletion ahead of purge
where this is needed.  And given the frequency this is needed, a
defined mechanism to do this would be useful.


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/20120511124132.gn23...@codelibre.net



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 06:39 PM, Gergely Nagy wrote:
 Long story short, I still don't see what the fuss is about.
   
 The fuss is about we're being told that there will be silent
 overwriting of configuration files without being prompted about
 changes, which potentially, will make it horrible to manage
 upgrades in a decent way without knowing the corner cases.

There will be no overwriting of configuration files. There might be
changes to defaults, like in every piece of software that is out there.

When defaults change, unless care is being taken, things will break,
indeed. That is not specific to systemd, and has nothing to do with its
defaults being under /lib/systemd.

Let me tell you three scenarios, just to demonstrate what I'm getting
at:

We have three programs:

* We have a program, that has a few defaults compiled in, and reads its
  configuration from /etc/program.conf. Lets call this the 'def-etc'
  program.

* We have another, that has no built in defaults, ships a config file in
  /etc/program/defaults.conf, and includes snippets from
  /etc/program/conf.d/. We'll call this 'def-conf.d'.

* We have a third program that comes with no compiled-in defaults, but
  has them in /lib/program instead. It reads configuration from snippets
  under /etc/program/. We'll call this 'def-lib'.

In the first case, since there is a single config file, lets assume we
modified that. In the other two cases, we placed snippets in the
appropriate directory, and did not touch the config file that contains
the default config.

When the first program changes its default, since it is compiled in, you
get no notofication, no prompt, no nothing - it wasn't in a config file,
it was compiled in.

When the second program changes its default, since you did not modify
the default config, that will be overwritten, and the only notice you
get is a Configuration file updated scrolling by, no prompt
whatsoever, no visible news, just something you've grown to expect, and
trust your tool to handle right.

When the third program changes its default, since you can't modifiy the
default config, you get no notification, no prompt, no nothing.

In all three cases, you get no prompt at all, because no tool in Debian
can handle the change of default settings. We're not prepared for that,
nor can we ever be. We can handle configuration change, but defaults are
*not* configuration. Configuration is things you're allowed to change.

 On top of that, we're being told that this is the reason why
 we should use this system, which is totally the inverse of
 what we've been doing in Debian for years.

I can't speak for anyone else who thinks etc-overrides-non-etc isn't the
work of the $devil, I merely think that this is a valid way to treat
default (unchangeable by the user) settings. It will not work for
everyone, nor should it.

But for specific cases, it is useful, and makes sense. That is all.

-- 
|8]


-- 
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/87zk9esxu3.fsf@algernon.balabit



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Michael Biebl
Am 11.05.2012 14:30, schrieb Marco d'Itri:
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).

This argument goes both ways, though. I've received more than one bug
report about uses fiddling with their sysv init scripts, then blindly
pressing ok during the upgrade or using non-interactive mode (which kept
the locally modified version) and the daemon failed to start due to
required changes being missing in the locally modified version.

Also, the recent discussions somehow make it look like you constantly
need to change the systemd .service files. This should only be necessary
in the rarest of cases.
Those systemd .service are in the vast majority of cases really simple
(most just containing the path to the executable and the type) and
comparable in complexity with dbus (system-)service files which have
been installed in /usr/share/dbus/ forever.

Michael



signature.asc
Description: OpenPGP digital signature


Getting power saving to work by default in wheezy

2012-05-11 Thread Touko Korpela
I think it would be nice if power saving options (SATA,USB,wireless
etc.) were turned on by default when running on laptop.
Powertop can report which kernel tunables are set (and you can use it to
turn individual options on/off).
Laptop task installs pm-utils by default.
There is also optional laptop-mode-tools with some overlap with pm-utils.
TLP Linux Advanced Power Management is another option (not yet in Debian)
https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management


-- 
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/20120511125924.GA25057@lisko



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Tollef Fog Heen
]] Gergely Nagy 

 Tollef Fog Heen tfh...@err.no writes:
 
  ]] Gergely Nagy 

  In that case, the including file can be changed (by the admin) to be a
  separate file, that does not include, and get the usual conffile
  conflict dpkg prompt.
 
  How would that work?
 
  I have /lib/systemd/system/foo.service and want to change something in
  it, I then create /etc/systemd/system/foo.service with a copy of the
  /lib one plus whatever changes I want.
 
  The version in /lib is then updated.  How is the admin notified?
 
 NEWS.Debian, like with any significant default change.

So you won't get the dpkg conffile conflict prompt, then?  Can you
explain what the scenario you talked about would look like, since it's
apparently not the scenario I was thinking about?

 Other than that, the best I can think of is keeping track of what
 version of the package a default changed in, and triggering something
 from preinst, when upgrading from a version that is older than the
 change.

This is basically what the tool I'm suggesting to write will do.

 This however, requires a lot of manual work, might aswell shovel the
 whole thing from under /lib to /etc then, but then we still didn't solve
 the problem: suppose there is a unit file that supports starting
 multiple instances, by way of symlinking. I start to use this feature,
 I change nothing, just symlink files around. At some point, this feature
 gets removed, my upgrade succeeds, but my instances won't start anymore,
 and the best notification I have is something that scrolled by that a
 conffile was upgraded.

You'll get a notification, since the file will have changed, then.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87boluopkt@qurzaw.varnish-software.com



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread SEEWEB - Marco d'Itri
On May 11, Michael Biebl bi...@debian.org wrote:

 You can either copy the file or use the .include directive (which was
 already mentioned) and only override the settings you need.
Not with udev or kmod.

  The problem with etc-overrides-lib is that a file must be copied in 
  full from /lib to /etc to be modified, and then future changes to the 
  same file in /lib will be ignored (so maybe the package will break 
  because these changes are required, etc).
 This argument goes both ways, though. I've received more than one bug
 report about uses fiddling with their sysv init scripts, then blindly
 pressing ok during the upgrade or using non-interactive mode (which kept
 the locally modified version) and the daemon failed to start due to
 required changes being missing in the locally modified version.
But this is a user error. The point is that with etc-overrides-lib there 
is no prompt at all when the upstream configuration changes.
This is good for Red Hat, because they can guarantee that no relevant 
changes will appear until the next major release, but is bad for us who 
actually support system upgrades.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 08:30 PM, Marco d'Itri wrote:
 On May 11, Thomas Goirand z...@debian.org wrote:

   
 Long story short, I still don't see what the fuss is about.
   
 The fuss is about we're being told that there will be silent
 overwriting of configuration files without being prompted about
 changes, which potentially, will make it horrible to manage
 upgrades in a decent way without knowing the corner cases.
 
 No, not even that: if you edit files in /lib without being aware of the 
 consequences then you are an idiot and deserve to suffer for it.
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).
   
Yes, that's exactly what I don't like, and what I want to avoid!!!

I want to be prompted, shown a diff, so I can see what's going on, and then
take my own decision based on this diff. So, in fewer words: the current
normal behavior in Debian.

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/4fad0f7a.2020...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 08:33 PM, Michael Biebl wrote:
 Am 11.05.2012 14:30, schrieb Marco d'Itri:
   
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).
 
 You can either copy the file or use the .include directive (which was
 already mentioned) and only override the settings you need.
 So systemd provides both semantics and you can chose which one you
 want/need.

 Michael
   
But upon upgrades, it's still a silent thing. The configuration file in /lib
is overwritten and users wont know about the changes.

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/4fad0fc2.4010...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 08:28 PM, David Weinehall wrote:
 Talking about yourself in pluralis majestatis now?
 Yes, I get it that you are.  Or are you somehow assuming that you can
 speak for all of Debian?  I guess you're aware of the fact that I'm a DD
 too?
   
By reading other replies, I thought there was only yourself and Uoti.
Now I can see that Gergely is also on your side, and then I don't
think there's a large consensus anymore.

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/4fad11f1.40...@debian.org



Bug#672482: ITP: gedit-projects -- Manage projects in gedit

2012-05-11 Thread B. Clausius
Package: wnpp
Severity: wishlist
Owner: B. Clausius ba...@gmx.de

* Package name: gedit-projects
  Version : 1.1
  Upstream Author : B. Clausius ba...@gmx.de
* URL : https://launchpad.net/gedit-projects
* License : GPL-3+
  Programming Lang: Python
  Description : Manage projects in gedit

 For this plugin a project is just a directory path. A list of last opened
 files is stored in the user config directory. In the project directory itself
 no data is stored or changed by the plugin. In the sidebar are two lists:
  * Open Projects: projects with at least one open file
  * All projects: project directories that are known to the plugin,
 projects that contain subprojects are shown in a tree structure
 .
 In the context menu you can perform some actions, including:
  * Open Project: restore all recently opened files of a project
  * View Project Folder: the project folder is opened with the default program
  * Close Project: all project files are closed (the file list is preserved)
  * Add Folder, Remove Folder: specify which folders are known as a project
  * Find Subprojects: search within the project folder for nested projects
 After installing and activating the plugin, you can invoke the settings
 dialog. There you can set up a directory that can be scanned for projects.
 Project directories are recognized by specific file names within the
 directory like VCS folders or files for build systems.



-- 
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/20120511132146.2976.85609.reportbug@System7



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 07:04 PM, Gergely Nagy wrote:
 Steve McIntyre st...@einval.com writes:

   
 Jean-Christophe Dubacq wrote:
 
 If dpkg kept a copy of the original configuration file (to be retrieved
 at all times), it would be easier to spot local changes.
 I use etckeeper to do that, but it's a bit tiresome to isolate all local
 changes (I have to save the diffs somewhere) (and a lost hope if you do
 install etckeeper late in the workstation life). My  git-fu is probably
 not good enough (I am probably looking for a pristine branch and a
 rebased local branch used in production).
   
 You might be interested in a proposal at UDS this week:

 https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles
 
 So basically, we'd have a directory of files under /etc that are not
 conffiles, and even made 0440. Amusing proposal.

 Why not move them outside of /etc then, if they are not configuration
 files, and should not be touched by the user?

 (Yeah, sure, they can be moved out of /etc, but that doesn't stop the
 original proposal being amusing, sorry.)
   
The setting of unix rights 0440 is indeed very amusing.

The only nice point about this proposal is that it's going to make happy
hard drive factories: they will be able to sell bigger hard drive for no
valid
good reasons.

Seriously, can't someone who broke his configuration wget the package,
and use mc to get into the .deb and get the original configuration file???

Overall, all this proposal assumes that users are idiots who love to change
things they don't understand, and aren't smart enough to restore. I can't
believe that newbies favorite game would be changing randomly the
content of /etc/init. And at the same time, I can't believe that experts
tweaking upstart jobs wouldn't know how to restore them.

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/4fad144c.1050...@debian.org



Bug#672484: ITP: gedit-classbrowser3g -- Class Browser for gedit

2012-05-11 Thread B. Clausius
Package: wnpp
Severity: wishlist
Owner: B. Clausius ba...@gmx.de

* Package name: gedit-classbrowser3g
  Version : 1.0
  Upstream Author : B. Clausius ba...@gmx.de
* URL : https://launchpad.net/gedit-classbrowser3g
* License : GPL-3+
  Programming Lang: Python
  Description : Class Browser for gedit

The class browser is located in the side pane and lists functions,
classes, etc. in a tree view. The default parser uses exuberant ctags
to support a wide range of languages. Special parsers are used for
Python, HTML, XML/Mallard/DocBook, Diff, Ruby and Markdown.



-- 
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/20120511133251.3329.87504.reportbug@System7



Re: Getting power saving to work by default in wheezy

2012-05-11 Thread Michael Biebl
On 11.05.2012 14:59, Touko Korpela wrote:
 I think it would be nice if power saving options (SATA,USB,wireless
 etc.) were turned on by default when running on laptop.
 Powertop can report which kernel tunables are set (and you can use it to
 turn individual options on/off).
 Laptop task installs pm-utils by default.
 There is also optional laptop-mode-tools with some overlap with pm-utils.
 TLP Linux Advanced Power Management is another option (not yet in Debian)
 https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management

pm-utils contains the pm-powersave tool, which is triggered via upower
when the AC state changes.

pm-powersave applies power saving settings, see the hooks in
/usr/lib/pm-utils/power.d/

Some of those are disabled by default, like the sata_alpm hook, since
they were reported to cause issues on certain hardware / driver
configurations in the past. We also removed hooks which have not proven
to be effective. Our decisions which hooks to enable/disable were also
based on Colin Kings fine work on that topic, who did actually measure
the influence of this settings on the power consumption:

https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-power-management
http://zinc.canonical.com/~cking/power-benchmarking/pm-utils-results/results.txt


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



signature.asc
Description: OpenPGP digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Nikolaus Rath
m...@linux.it (Marco d'Itri) writes:
 On May 11, Nikolaus Rath nikol...@rath.org wrote:

  Wrong: since you have to copy the whole file to override it, and files 
  in /lib have no conffiles handling, after an upgrade you will not know 
  what was changed by you and what was changed upstream.
 I think everyone here agrees with that. The interesting case is when
 files in /etc/ can either explicitly include the /lib file, or
 implicitly override the /lib settings.
 I do not know about any package which work this way,

Well, systemd has been mentioned one or two times here in the last
weeks.

 but there is any 
 then the problem is not different from packages which support multiple 
 configuration file fragments in /etc, ship the default configuration 
 in /etc and allow it to be modified by other configuration fragments in 
 /etc (e.g. Apache).

I agree, and therefore I'm surprised that some people are getting so
aggravated about this if the default configuration is installed in /lib
rather than /etc.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


-- 
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/8762c27shc@inspiron.ap.columbia.edu



Re: Getting power saving to work by default in wheezy

2012-05-11 Thread Ritesh Raj Sarraf
On Friday 11 May 2012 06:29 PM, Touko Korpela wrote:
 I think it would be nice if power saving options (SATA,USB,wireless
 etc.) were turned on by default when running on laptop.
 Powertop can report which kernel tunables are set (and you can use it to
 turn individual options on/off).
 Laptop task installs pm-utils by default.
 There is also optional laptop-mode-tools with some overlap with pm-utils.
 TLP Linux Advanced Power Management is another option (not yet in Debian)
 https://github.com/linrunner/TLP/wiki/TLP-Linux-Advanced-Power-Management
For laptop-mode-tools, it is enabled by default. We have a whilelist of
modules that are ON when you install. And all of what you have mentioned
is already in the whitelist.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
Necessity is the mother of invention.




signature.asc
Description: OpenPGP digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marvin Renich
* Thomas Goirand z...@debian.org [120511 04:45]:
 On 05/11/2012 04:04 AM, David Weinehall wrote:
 From: http://en.wikipedia.org/wiki/Configuration_file
 
 In computing, configuration files, or config files configure the initial
 settings for some computer programs. They are used for user applications,
 server processes and operating system settings.
 
 The fact that these files are in /lib and shouldn't be touched by the admin
 doesn't make them less configuration files. They still match the above
 definition from Wikipedia.
 
  And debian-policy isn't set in stone.
  Otherwise it wouldn't have last been revised in February 2012 :)

 
 The debian-policy maybe, but the FHS, and config files in /etc *is* a very
 strong policy that you will not change in Debian, and for very valid
 reasons already described in this thread.

The FHS is very specific that /etc is for *Host-specific* system
configuration, not upstream defaults or distribution-specific
configuration.  The clear intent is that this is where files that are
intended to be modified by the local system administrator are placed.
Files containing distribution-specific defaults, whether they match some
definition of configuration file or not, do not belong here unless the
they are also intended to be edited by the local sysadmin.

Using a Wikipedia definition must be done with careful consideration, as
they are often either over generalized or too specific.  In this case I
believe the Wikipedia definition is not in the least relevant to the
subtleties being disputed here.

Debian policy does not explicitly differentiate between host-specific
configuration and Debian-provided default configuration, but it does
say, Typically, configuration files are intended to be modified by the
system administrator (if needed or desired) to conform to local policy
or to provide more useful site-specific behavior.

Following the FHS is, however, a must in Debian policy except where
policy explicitly provides an exception or conflicts with the FHS.

It is clear to me that etc-overrides-non-etc is perfectly compliant with
Debian policy as long as the sysadmin does not need to modify the
non-etc files to obtain the desired behavior.

I have been using Debian since 1998, and IME the cases where changes to
the Debian-supplied configuration files would have caused breakage if
the Debian defaults had been in /usr/lib/package and only local
modifications were in /etc have been rare.  On the other hand, the cases
where this model would have both obviated the need for a manual merge
and resulted in exactly the configuration I intended are extremely
common.

Gergely Nagy has shown elsewhere in this thread that no matter which
configuration model you use, there are cases where you might not get a
notification of incompatible default configuration from dpkg on upgrade.
On the other hand, the etc-overrides-non-etc model significantly
simplifies most of the common default-configuration-change cases.

For clarity, the etc-overrides-non-etc model that I am talking about is
where the file in /etc can override individual values, not where the
file in /etc must replace the entirety of the non-etc configuration.

While I agree that etc-overrides-non-etc may not be the best model for
all software, it is the best for some and at least as good for many
other packages.

...Marvin


-- 
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/20120511150832.ga7...@cleo.wdw



Bug#672499: ITP: rake-compiler -- Rake-based Ruby Extension (C, Java) task generator

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: rake-compiler
  Version : 0.8.1
  Upstream Author : Luis Lavena
* URL or Web page : http://github.com/luislavena/rake-compiler
* License : Expat 
  Description : Rake-based Ruby Extension (C, Java) task generator

 The rake-compiler is first and foremost a productivity tool for Ruby
 developers. It's goal is to make the busy developer's life easier by
 simplifying the building and packaging of Ruby extensions by
 simplifying code and reducing duplication.
 .
 It follows *convention over configuration* by advocating a standardized
 build and package structure for both C and Java based RubyGems.
 .
 Rake-compiler is the result of many hard-won experiences dealing with
 several diverse RubyGems that provided native extensions for different
 platforms and different user configurations in different ways. Details
 such as differences in code portability, differences in code clarity,
 and differences in project directory structure often made it very
 difficult for newcomers to those RubyGems.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87ipg2d83j.wl%uwab...@gfd-dennou.org



Bug#672501: ITP: ruby-albino -- Ruby wrapper for pygments

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-albino
  Version : 1.3.3
  Upstream Author : Chris Wanstrath
* URL or Web page : http://github.com/github/albino
* License : Expat
  Description : Ruby wrapper for pygments

 Albino is a ruby wrapper for python-pygmentize.
 .
 Pygments aims to be a generic syntax highlighter for general use in all
 kinds of software such as forum systems, wikis or other applications
 that need to prettify source code.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87havmd802.wl%uwab...@gfd-dennou.org



Bug#672503: ITP: ruby-classifier -- Ruby module to allow Bayesian and other types of classifications

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-classifier
  Version : 1.3.3
  Upstream Author : Lucas Carlson, David Fayram II, Cameron McBride
* URL or Web page : http://classifier.rufy.comp
* License : LGPL-2.0+
  Description : Ruby module to allow Bayesian and other types of 
classifications

 Classifier is a general module to allow Bayesian and other types of
 classifications.
 .
 This package provides Bayes classifier and Latent Semantic
 Indexer. Bayesian Classifiers are accurate, fast, and have modest
 memory requirements. Latent Semantic Indexing engines are not as fast
 or as small as Bayesian classifiers, but are more flexible, providing
 fast search and clustering detection as well as semantic analysis of
 the text that theoretically simulates human learning.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87fwb6d7v1.wl%uwab...@gfd-dennou.org



Re: Configuration file handling

2012-05-11 Thread Russ Allbery
Roger Leigh rle...@codelibre.net writes:

 I would much rather we had a more general mechanism of storing the real
 configuration files (as opposed to just md5s) by dpkg itself, which
 would enable proper merging of admin changes between old and new
 conffiles, and perhaps also allow dpkg to implement ucf-like conffile
 handling (or remove the need for ucf entirely).  These could be stored
 under /var/lib/dpkg/conffiles (for example).

Yes, this.  The current method for restoring a deleted or modified
configuration file to its original state in the absence of add-on tools
like etckeeper is relentlessly obscure.  I've had to walk very experienced
UNIX admins through it, since the various things you have to do are very
unintuitive.  We need to do better, including a top-level, user-visible
command to easily restore the pristine configuration of a package.

We could get some of the way there by having a standard option to apt-get
and aptitude to reinstall a package with --force-confnew --force-confmiss,
but better support at the dpkg layer lets us also do other interesting
things, as you note.

 On a related note...
 While we might criticise rpm for its bad conffile handling, dpkg is
 itself fairly woeful, and if we change one thing for wheezy+1, it should
 be sane conffile handling.  dpkg should never forget about conffiles;
 the fact that maintainer scripts have to take care of purging such files
 is a glaring defect, and possibly the source of the greatest fragility
 in our maintainer scripts--it's impossible for maintainer scripts to get
 this right all the time given all the corner cases like downgrades and
 being taken over by other packages.  If this was implemented robustly,
 the maintainer script should never need to concern itself with such
 cleanup, or indeed any manual work with conffiles at all, except maybe
 for deletion ahead of purge where this is needed.  And given the
 frequency this is needed, a defined mechanism to do this would be
 useful.

Agreed.

The criticisms of rpm are nice for making us feel better ourselves and
helping get rid of the lingering trauma of having used Red Hat (speaking
for myself at least *grin*), but they don't make Debian any better.  We
have some significant problems ourselves that we could fix.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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



Bug#672505: ITP: ruby-fast-stemmer -- Ruby module of Fast Porter stemmer based on a C version algorithm

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-fast-stemmer
  Version : 1.0.1
  Upstream Author : Roman Shterenzon
* URL or Web page : http://github.com/romanbsd/fast-stemmer
* License : Expat
  Description : Ruby module of Fast Porter stemmer based on a C version 
algorithm

 Fast-stemmer is simply a wrapping around multithreaded Porter stemming
 algorithm.
 .
 This module adds a String::stem method, and it's in order of magnitude
 faster (and uses much less memory) than the pure Ruby implementation of
 stemmer.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87ehqqd7pu.wl%uwab...@gfd-dennou.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Russ Allbery
Thomas Goirand z...@debian.org writes:

 Section 10.7.2 of dpm:

 Any configuration files created or used by your package must reside in
 |/etc|.

Configuration file is a term of art that is previously defined in the
Policy document.  It doesn't mean what you're taking it to mean.

There isn't anything about etc-overrides-lib that violates the letter of
Policy.  (The expectations of a Debian administrator are another
question.)

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
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/8739767l76@windlord.stanford.edu



Bug#672506: ITP: ruby-directory-watcher -- Watch directory/files and Generate events by file change

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-directory-watcher
  Version : 1.4.1
  Upstream Author : Tim Pease
* URL or Web page : http://gemcutter.org/gems/directory_watcher
* License : Expat
  Description : Watch directory/files and Generate events by file change

 The directory watcher operates by scanning a directory at some interval
 and generating a list of files based on a user supplied glob
 pattern. As the file list changes from one interval to the next, events
 are generated and dispatched to registered observers.
 .
 Three types of events are supported - added, modified, and removed.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87d36ad7k0.wl%uwab...@gfd-dennou.org



Bug#672507: ITP: ruby-posix-spawn -- Ruby Implementation of posix_spawn(2) for faster process spawning

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-posix-spawn
  Version : 0.3.6
  Upstream Author : Ryan Tomayko, Aman Gupta 
* URL or Web page : http://github.com/rtomayko/posix-spawn
* License : LGPL-2.1+, Expat
  Description : Ruby Implementation of posix_spawn(2) for faster process 
spawning

 The posix-spawn library aims to implement a subset of the Ruby 1.9
 `Process::spawn` interface in a way that takes advantage of fast
 process spawning interfaces when available and provides sane fallbacks
 on systems that do not.
 .
 `fork(2)` calls slow down as the parent process uses more memory due to
 the need to copy page tables. In many common uses of fork(), where it
 is followed by one of the exec family of functions to spawn child
 processes (`Kernel#system`,`IO::popen`, `Process::spawn`, etc.), it's
 possible to remove this overhead by using the use of special process
 spawning interfaces (`posix_spawn()`, `vfork()`, etc.)

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87bolud7d6.wl%uwab...@gfd-dennou.org



Bug#672508: ITP: ruby-redcarpet -- Fast, safe and extensible Markdown to (X)HTML parser written in Ruby

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: ruby-redcarpet
  Version : 2.1.1
  Upstream Author : Natacha Porte', Vincent Marti
* URL or Web page : http://github.com/tanoku/redcarpet
* License : Expat
  Description : Fast, safe and extensible Markdown to (X)HTML parser for 
Ruby

 Redcarpet is Ruby library for Markdown processing. This library provides
 fast, safe and extensible Markdown to (X)HTML parser.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/87aa1ed6yg.wl%uwab...@gfd-dennou.org



Bug#672509: ITP: jekyll -- Simple, blog aware, static site generator written in Ruby

2012-05-11 Thread Youhei SASAKI
Package: wnpp
Owner: Youhei SASAKI uwab...@gfd-dennou.org
Severity: wishlist

* Package name: jekyll
  Version : 0.11.2
  Upstream Author : Tom Preston-Werner
* URL or Web page : http://github.com/mojombo/jekyll
* License : Expat
  Description : Simple, blog aware, static site generator written in Ruby

 Jekyll is a simple, blog aware, static site generator. It takes a
 template directory (representing the raw form of a website), runs it
 through Textile or Markdown and Liquid converters, and spits out a
 complete, static website suitable for serving with Apache or your
 favorite web server.
 .
 This is also the engine behind GitHub Pages(http://pages.github.com),
 which you can use to host your project's page or blog right here from
 GitHub.

---
Youhei SASAKI uwab...@gfd-dennou.org
  uwab...@debian.or.jp
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07



-- 
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/878vgyd6up.wl%uwab...@gfd-dennou.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Jean-Christophe Dubacq
On 11/05/2012 15:29, Thomas Goirand wrote:

 The setting of unix rights 0440 is indeed very amusing.

Yes. Maybe the mean to chmod a-w everything, for some applications will
not work with so large modes (sudo, for example).

 The only nice point about this proposal is that it's going to make happy
 hard drive factories: they will be able to sell bigger hard drive for no
 valid
 good reasons.

Come on! Less than 20M, it could trivially be compressed.

 Seriously, can't someone who broke his configuration wget the package,
 and use mc to get into the .deb and get the original configuration file???

Not necessarily.

1) Many configuration files are dynamically generated through debconf
questions, which root may not be able to rerun to obtain the same result.
2) What if you borked your network configuration? What if the
malfunction is due to a complex interaction between several packages
(let's say, a FORCESSL option on some service A, and a libssl upgrade
breaks A but only if the FORCESSL option is used?) Being able
3) I think etckeeper could do the job without much development. However,
it will make the hard drive factories happy (according to you).

 Overall, all this proposal assumes that users are idiots who love to change
 things they don't understand, and aren't smart enough to restore. I can't
 believe that newbies favorite game would be changing randomly the
 content of /etc/init. And at the same time, I can't believe that experts
 tweaking upstart jobs wouldn't know how to restore them.

I find your attitude assumes users always have the knowledge and the
time to investigate everything. This is not the reality.

Sincerly,
-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/11/2012 11:08 PM, Marvin Renich wrote:
 For clarity, the etc-overrides-non-etc model that I am talking about is
 where the file in /etc can override individual values, not where the
 file in /etc must replace the entirety of the non-etc configuration.
   
This case is much much more acceptable to me. I wouldn't see any
problem with it. I just don't want that new configuration values to be
silently ignored upon upgrades, that's all I'm saying.

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/4fad3cb8.1080...@debian.org



Re: Bug#672507: ITP: ruby-posix-spawn -- Ruby Implementation of posix_spawn(2) for faster process spawning

2012-05-11 Thread Julien Cristau
On Sat, May 12, 2012 at 01:12:37 +0900, Youhei SASAKI wrote:

 Package: wnpp
 Owner: Youhei SASAKI uwab...@gfd-dennou.org
 Severity: wishlist
 
 * Package name: ruby-posix-spawn

Do you really need a whole package for a single syscall wrapper?

Cheers,
Julien


signature.asc
Description: Digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Thomas Goirand
On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
 I find your attitude assumes users always have the knowledge and the
 time to investigate everything. This is not the reality.

 Sincerly,
   
Not at all. Anyone without the knowledge will not be able to
restore anything anyway.

Anyone with the knowledge will know how to get the original file.
Yes, it will take more time to do that, but do you think this is
the kind of operation you need to do every day? I'd say, once
every 5 years maybe?

Very rarely, I do a purge then reinstall, but never it happened
to me that my system was in such state that I had to recover
by hand a configuration file, using the single user boot. Did
this happen to you at some point? Anyone else?

I'm not bashing the idea so much, as it is a harmless one, I just
think it is simply a useless feature, and I don't think it's worth
investing any human time on this.

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/4fad4670.5030...@debian.org



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Jean-Christophe Dubacq
On 11/05/2012 19:03, Thomas Goirand wrote:
 On 05/12/2012 12:22 AM, Jean-Christophe Dubacq wrote:
 I find your attitude assumes users always have the knowledge and the
 time to investigate everything. This is not the reality.

 Sincerly,
   
 Not at all. Anyone without the knowledge will not be able to
 restore anything anyway.
 
 Anyone with the knowledge will know how to get the original file.
 Yes, it will take more time to do that, but do you think this is
 the kind of operation you need to do every day? I'd say, once
 every 5 years maybe?
 
 Very rarely, I do a purge then reinstall, but never it happened
 to me that my system was in such state that I had to recover
 by hand a configuration file, using the single user boot. Did
 this happen to you at some point? Anyone else?

Yes, several times indeed. Most times when upgrading network packages at
the same time.

 I'm not bashing the idea so much, as it is a harmless one, I just
 think it is simply a useless feature, and I don't think it's worth
 investing any human time on this.

I think it would be really great to have some program being able to
output all manual differences to all /etc files really useful for
maintenance. I used to do that, but some rapidly evolving configuration
files make it quickly unmaintainable (php.ini comes to mind: I always
have to put back the upload_max_filesize to a superior value, and this
one-line difference makes something that should be really, really simple
(upgrading php, even using stable+security) a pain because one gets
manually prompted about the differences, even if they are trivial to merge.


-- 
Jean-Christophe Dubacq



signature.asc
Description: OpenPGP digital signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 Seriously, can't someone who broke his configuration wget the package,
 and use mc to get into the .deb and get the original configuration
 file???

FWIW, I'd love an easier way to keep track of my /etc, where upstream
changes and my own are on a separate branch. So the idea is not entirely
silly, and would be useful even for folk like myself, who - at least I
dare hope so - are not entirely clueless.

The solution, however, is very simple: wrap dpkg calls, and have a list
of files to watch for. Whenever a package touches a file that's on the
list, fire a trigger, that can run a hook. Said hook can be something
provided by etckeeper or similar, that would extract the appropriate
file from the deb, and commit it to the upstream branch of /etc, for
example.

Then proceed on, and do whatever else needs to be done. And boom! We
have a way to allow experienced users to keep track of their /etc
properly, that does not fall on its face when I notice a bad config
change in the upstream config two updates later.

Oh, and this whole thing need not live in /etc at all, and can follow
anything, not just config files. It's perfectly able to notice changes
in /lib/systemd too, or pretty much anywhere else.

I actually just implemented that (it took 10 minutes, becuase I screwed
up first), and will be testing how it works over the next few weeks.

-- 
|8]


-- 
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/87y5oyr0eq@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
m...@linux.it (Marco d'Itri) writes:

 On May 11, Thomas Goirand z...@debian.org wrote:

  Long story short, I still don't see what the fuss is about.
 The fuss is about we're being told that there will be silent
 overwriting of configuration files without being prompted about
 changes, which potentially, will make it horrible to manage
 upgrades in a decent way without knowing the corner cases.
 No, not even that: if you edit files in /lib without being aware of the 
 consequences then you are an idiot and deserve to suffer for it.
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).

And...?

If it were somewhere under /usr/share/doc/$package/examples, how would
that be different? (Assuming that the *default* would then be wired into
the binary)

You'd still need to copy the file, and if the defaults change under you,
you're screwed. Even worse if you have to dig out the possible options,
and their defaults from (possibly stale) documentation.

But even if everything is in /etc, you can still easily screw yourself
over: conf.d/ can very easily break the exact same way.

It's not etc-overrides-lib that is the problem. It's defaults changing
without notice that is. With the defaults being broken out into files,
making a tool that notifies the user preemptively when a default will
change, and stops the upgrade, is possible, and is not even hard.

You can't do that when the defaults are either unavailable, or subject
to change by the admin.

-- 
|8]


-- 
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/87r4uqqzwt@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 08:33 PM, Michael Biebl wrote:
 Am 11.05.2012 14:30, schrieb Marco d'Itri:
   
 The problem with etc-overrides-lib is that a file must be copied in 
 full from /lib to /etc to be modified, and then future changes to the 
 same file in /lib will be ignored (so maybe the package will break 
 because these changes are required, etc).
 
 You can either copy the file or use the .include directive (which was
 already mentioned) and only override the settings you need.
 So systemd provides both semantics and you can chose which one you
 want/need.

 Michael
   
 But upon upgrades, it's still a silent thing. The configuration file in /lib
 is overwritten and users wont know about the changes.

Likewise for *every* other case where the default changes. There's
nothing different. Nothing. Nada.

Except you can write a tool to warn in *this* case, because the defaults
are available in a diffable format.

-- 
|8]


-- 
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/87mx5eqztf@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Vincent Bernat
OoO Peu  avant le début  de l'après-midi du  vendredi 11 mai  2012, vers
13:20, Gergely Nagy alger...@balabit.hu disait :

 In other words, it does *exactly* the same thing systemd is
 criticised for.
 
 
 Which doesn't mean that it's a good practice.

 Tell me what you would gain, if there were no files under /lib/systemd,
 and all of these were compiled into the binary, please. Because that's
 the other option, as you *do not* let users change the defaults. You let
 them override them, you let them configure the system. (And that *is*
 being done in /etc.)

 There are *very* few programs that come without any kind of default, and
 even less, that let you change the default too.

 apt does not let you change the defaults, nor does dpkg. Both allow you
 to change their settings, but without recompiling, you can't change the
 defaults. Same happens with systemd, the difference is that it's easier
 to see the defaults, as they're broken out into files that are easy to
 copy and change as needed.

Yes, that's very  true. We are just used that the  kind of defaults in
init to  be in /etc. But  nothing is set  in stone. I was  first against
this etc-override-lib  behaviour but your  arguments are sound and  I am
now convinced that we should keep the way systemd is doing things.

Moreover, in the case of systemd, there are other mechanisms that can be
used to customize a configuration file for the more common modifications
(handling  dependencies and  ordering) using  symbolic links.  This way,
there  is  no need  to  copy  the  file from  /lib  in  /etc to  do  the
modifications.

Still in the  case of systemd, a README put in  /etc/systemd may be used
to explain  the whole etc-override-lib  to users that are  not expecting
such behaviour. A README is not a configuration file but there is one in
/etc/init.d as well.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

#if 0
2.2.16 /usr/src/linux/fs/buffer.c


pgpOoyGiMli3V.pgp
Description: PGP signature


Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
SEEWEB - Marco d'Itri m...@seeweb.it writes:

 But this is a user error. The point is that with etc-overrides-lib there 
 is no prompt at all when the upstream configuration changes.

Bzzt. There's no prompt ever when upstream defaults change. Unless *all*
the defaults are laid out in /etc, *AND* the user modified that
particular file.

If suddenly /etc/$program.conf, which I never modified changes, and I
have custom snippets under /etc/$program.d/*.conf, those snippets might
very well break.

Do I get a prompt? No. The closest I get is that $program.conf was
upgraded. I see no diff, unless I keep track of my /etc in other ways.

-- 
|8]


-- 
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/87ipg2qzmc@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Thomas Goirand z...@debian.org writes:

 On 05/11/2012 11:08 PM, Marvin Renich wrote:
 For clarity, the etc-overrides-non-etc model that I am talking about is
 where the file in /etc can override individual values, not where the
 file in /etc must replace the entirety of the non-etc configuration.
   
 This case is much much more acceptable to me. I wouldn't see any
 problem with it. I just don't want that new configuration values to be
 silently ignored upon upgrades, that's all I'm saying.

I agree, that seeing the defaults change would be lovely. With the
defaults being in /lib, it's possible to write a tool that notifies you.

With the defaults being in a monolithic blob, possibly inside a binary,
it is not.

-- 
|8]


-- 
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/87ehqqqzeu@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Gergely Nagy
Tollef Fog Heen tfh...@err.no writes:

 ]] Gergely Nagy 

 Tollef Fog Heen tfh...@err.no writes:
 
  ]] Gergely Nagy 

  In that case, the including file can be changed (by the admin) to be a
  separate file, that does not include, and get the usual conffile
  conflict dpkg prompt.
 
  How would that work?
 
  I have /lib/systemd/system/foo.service and want to change something in
  it, I then create /etc/systemd/system/foo.service with a copy of the
  /lib one plus whatever changes I want.
 
  The version in /lib is then updated.  How is the admin notified?
 
 NEWS.Debian, like with any significant default change.

 So you won't get the dpkg conffile conflict prompt, then?  Can you
 explain what the scenario you talked about would look like, since it's
 apparently not the scenario I was thinking about?

I believe we're talking about the same scenario, and I was hasty to
suggest that NEWS.Debian is the only way - see below.

 Other than that, the best I can think of is keeping track of what
 version of the package a default changed in, and triggering something
 from preinst, when upgrading from a version that is older than the
 change.

 This is basically what the tool I'm suggesting to write will do.

During my trip back home, I wrote that tool. It's very crude and hackish
at the moment, but with a little bit of support from, say, apt (or
perhaps dpkg, but that's less likely), it could be made into something
nice.

Basically, I divert dpkg, and catch all -i calls, see what debs we're
called on, list the files therein. If any of the files are on the
watchlist, I launch the triggers, with apropriate parameters. The only
trigger I have implemented so far will extract the files that triggered
it, and put them in version control, onto the appropriate upstream
branch. Then proceed on.

I could enhance it to abort the installation, or send mail, or pause and
do some ucf magic, to check whether overrides in /etc exist at all, and
so on and so forth.

I only needed the shovel-into-a-vcs-branch thing, so that's what I
have. Adding the rest isn't hard, either.

The advantage here, is that the packager need not keep track of what
changed in which version, and admins can extend the watchlist, and
change the triggered actions too, to make it better suit their own
needs. This also means that in case of bugs, we don't need to fix
maintainer scripts, just a single application.

-- 
|8]


-- 
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/87aa1eqz1g@luthien.mhp



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Steve Langasek
On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
 The FHS is very specific that /etc is for *Host-specific* system
 configuration, not upstream defaults or distribution-specific
 configuration.  The clear intent is that this is where files that are
 intended to be modified by the local system administrator are placed.

No, this is a total retcon.  When the FHS was written, this was definitely
NOT a shared understanding of a difference between host-specific
configuration and upstream defaults / distribution-specific
configuration.

Distribution defaults still would go in /etc whenever it was expected that
an admin might want to edit the file.  This has been the convention for more
than a decade.

 Files containing distribution-specific defaults, whether they match some
 definition of configuration file or not, do not belong here unless the
 they are also intended to be edited by the local sysadmin.

Yes.  The issue is not that either system is a violation of the standard,
because intent is relevant here.  If the upstream *intends* the file to be a
template that's overridden using a separate file, then /usr is the right
place.  If the upstream intends the user to edit the provided file to make
their changes, it belongs in /etc.  If the defaults are built into the
binary, that's perfectly fine too.

What *is* an issue is when upstreams decide to ship their defaults in /usr,
but require users to duplicate information between /usr templates and /etc
config files and ignore the contents of /usr in favor of the contents of
/etc.  This is also not a violation of FHS, but it IS a crappy design.

When software is not able to override configuration *settings* with fine
granularity via /etc, the entire thing should go under /etc.  Doing
otherwise makes this horrible for upgrades.

-- 
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: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Russ Allbery
Steve Langasek vor...@debian.org writes:

 What *is* an issue is when upstreams decide to ship their defaults in
 /usr, but require users to duplicate information between /usr templates
 and /etc config files and ignore the contents of /usr in favor of the
 contents of /etc.  This is also not a violation of FHS, but it IS a
 crappy design.

 When software is not able to override configuration *settings* with fine
 granularity via /etc, the entire thing should go under /etc.  Doing
 otherwise makes this horrible for upgrades.

Yes, this, with the caveat that coming up with a new tool that would do
the right thing, as Tollef discussed, would be a reasonable substitute for
putting everything in /etc.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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



Re: RFC: OpenRC as Init System for Debian

2012-05-11 Thread Marvin Renich
* Steve Langasek vor...@debian.org [120511 16:17]:
 On Fri, May 11, 2012 at 11:08:32AM -0400, Marvin Renich wrote:
  The FHS is very specific that /etc is for *Host-specific* system
 
 No, this is a total retcon.  When the FHS was written, this was definitely
 NOT a shared understanding of a difference between host-specific
 configuration and upstream defaults / distribution-specific
 configuration.

I obviously read more into host-specific than was intended.

 Distribution defaults still would go in /etc whenever it was expected that
 an admin might want to edit the file.  This has been the convention for more
 than a decade.

Agree completely.  See the next sentence.

  Files containing distribution-specific defaults, whether they match some
  definition of configuration file or not, do not belong here unless the
  they are also intended to be edited by the local sysadmin.
 
 Yes.  The issue is not that either system is a violation of the standard,
 because intent is relevant here.  If the upstream *intends* the file to be a
 template that's overridden using a separate file, then /usr is the right
 place.  If the upstream intends the user to edit the provided file to make
 their changes, it belongs in /etc.  If the defaults are built into the
 binary, that's perfectly fine too.

I agree completely.  I was responding specifically to the assertion that
the definition of configuration file from Wikipedia meant that Debian
must put files containing distribution-specific defaults in /etc,
regardless of whether or not they were intended to be modified by the
local sysadmin.

 What *is* an issue is when upstreams decide to ship their defaults in /usr,
 but require users to duplicate information between /usr templates and /etc
 config files and ignore the contents of /usr in favor of the contents of
 /etc.  This is also not a violation of FHS, but it IS a crappy design.

Again, I agree completely.  See the part of my message that you did not
include where I clarified to which etc-overrides-non-etc model I was
referring.

 When software is not able to override configuration *settings* with fine
 granularity via /etc, the entire thing should go under /etc.  Doing
 otherwise makes this horrible for upgrades.

Absolutely.  Again, see my clarification of how I was using
etc-overrides-non-etc.  I did not go into what I think is wrong with
default in /usr, copy entirety to /etc and edit in order to override a
single setting because I was specifically trying to address the other
poster's assertion that placing anything that matches the Wikipedia
definition of configuration file anywhere other than /etc was a
violation of a must in Debian policy.

...Marvin


-- 
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/20120511210825.gc7...@cleo.wdw



Bug#672549: ITP: libballoontip-java -- Balloon Tips for Java

2012-05-11 Thread Stefan Handschuh
Package: wnpp
Severity: wishlist
Owner: Stefan Handschuh handschuh.ste...@googlemail.com

* Package name: libballoontip-java
  Version : 1.2.1
  Upstream Author : Bernhard Pauler bernhard_pau...@dev.java.net, Tim 
Molderez nfe...@dev.java.net
* URL : http://java.net/projects/balloontip
* License : BSD
  Programming Lang: Java
  Description : Balloon Tips for Java

Provides balloon-tips for use in Java Swing applications to be laid over any
kind of swing-component such as JButton.



-- 
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/20120511222824.5669.99716.reportbug@m1330



Re: Licenses not in /usr/share/common-licenses

2012-05-11 Thread Michael Gilbert
On Tue, May 8, 2012 at 1:49 PM, Matthew Woodcraft wrote:
 Russ Allbery wrote:
 I think the core question is: why is base-files special? Yes, it's
 essential and all, but that doesn't address the case of packages being
 downloaded separate from Debian, or unpacked by hand, in which case we
 don't include a license. If we're legally fine with that, I'm having a
 hard time seeing the clear distinction between that and a dependency
 on another package including the license.

 Surely this has been discussed before? I don't remember seeing it on
 the debian-policy list since I started working on Policy.

 There's a fairly lengthy discussion starting at
 http://lists.debian.org/debian-policy/2000/11/msg00235.html

So, I think [0] is the most astute message in that thread.
Succinctly, the copyright file itself is irrelevant in the source
package since the upstream source should have all of that information
already, and at least for the GPL you can distribute source packages
as is.  Thus, the issue is reduced to the need for full license texts
only in all binary packages.

That doesn't seem to be a current requirement and copyright file
symlinks are often used today, so perhaps a first step would be to
make that a part of the Debian policy?

Secondly, since the copyright file in the source package doesn't
actually need full license text, license file references should be
allowable there; as long as appropriate helpers are written that can
take those (reference only) source copyright files and fill in the
appropriate full license texts for the binary files that it generates.

Eliminating the tedium of copying, pasting, and reformatting license
texts would be a wonderful simplification and time reducer.

Best wishes,
Mike

[0] http://lists.debian.org/debian-policy/2000/11/msg00251.html


-- 
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/CANTw=morcraz-_5bi0bfo82e6ekhdkpp_g1cyoedcpgs_qh...@mail.gmail.com



Re: Configuration file handling (was: RFC: OpenRC as Init System for Debian)

2012-05-11 Thread Guillem Jover
On Fri, 2012-05-11 at 13:41:32 +0100, Roger Leigh wrote:
 On Fri, May 11, 2012 at 11:53:34AM +0100, Steve McIntyre wrote:
  Jean-Christophe Dubacq wrote:
  If dpkg kept a copy of the original configuration file (to be retrieved
  at all times), it would be easier to spot local changes.
  I use etckeeper to do that, but it's a bit tiresome to isolate all local
  changes (I have to save the diffs somewhere) (and a lost hope if you do
  install etckeeper late in the workstation life). My  git-fu is probably
  not good enough (I am probably looking for a pristine branch and a
  rebased local branch used in production).
  
  You might be interested in a proposal at UDS this week:
  
  https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-dpkg-pristine-conffiles

I've just skimmed over this, and at first sight I'm not planning on
merging something like that into dpkg.

 I would much rather we had a more general mechanism of storing the
 real configuration files (as opposed to just md5s) by dpkg itself,
 which would enable proper merging of admin changes between old and
 new conffiles, and perhaps also allow dpkg to implement ucf-like
 conffile handling (or remove the need for ucf entirely).  These
 could be stored under /var/lib/dpkg/conffiles (for example).

This has been discussed before, it's on dpkg's roadmap, there's even
some draft code by Sean Finney, but the semantics where not right. I
started reworking it some time ago, and it's on my short term TODO,
either for 1.16.x or 1.17.x.

regards,
guillem


-- 
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/20120512020303.ga23...@gaara.hadrons.org



Re: Licenses not in /usr/share/common-licenses

2012-05-11 Thread Russ Allbery
Michael Gilbert michael.s.gilb...@gmail.com writes:

 So, I think [0] is the most astute message in that thread.

 [0] http://lists.debian.org/debian-policy/2000/11/msg00251.html

I thought that too when I first read it, but later in the thread are very
cogent arguments for why it's wrong and providing a complete copy of the
GPL with binaries is required.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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



Re: Licenses not in /usr/share/common-licenses

2012-05-11 Thread Charles Plessy
Le Fri, May 11, 2012 at 10:10:17PM -0400, Michael Gilbert a écrit :
 
 Succinctly, the copyright file itself is irrelevant in the source
 package since the upstream source should have all of that information
 already, and at least for the GPL you can distribute source packages
 as is.  Thus, the issue is reduced to the need for full license texts
 only in all binary packages.

Hi all,

given that the source and binary packages are considered a single entity --
otherwise we would be violating the GPLs v1 and v2 -- the Debian copyright file
is not necessary from a strictly legal point of view.

It is therefore a facility to our infrastructure and a service to our users,
and it is up to us as a project to decide its contents.  One unwritten rule is
that it has to contain all the necessary information for the FTP team to review
the package.  A first step in order to lift the requirement to include a 
verbatim
copy of all licenses that are not distributed in /usr/share/common-licenses
would be to ask the FTP team their opinion on that matter.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512023757.gb29...@falafel.plessy.net



Re: Licenses not in /usr/share/common-licenses

2012-05-11 Thread Russ Allbery
Charles Plessy ple...@debian.org writes:

 given that the source and binary packages are considered a single entity
 -- otherwise we would be violating the GPLs v1 and v2 -- the Debian
 copyright file is not necessary from a strictly legal point of view.

I don't see the logical justification for this statement.  Our compliance
with the GPL does not rely on considering source and binary packages as a
single entity.  The GPL explicitly permits us to treat them as two
separate entities and distribute the source separately (which is what we
do).

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


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



Re: Licenses not in /usr/share/common-licenses

2012-05-11 Thread Charles Plessy
Le Fri, May 11, 2012 at 07:52:05PM -0700, Russ Allbery a écrit :
 Charles Plessy ple...@debian.org writes:
 
  given that the source and binary packages are considered a single entity
  -- otherwise we would be violating the GPLs v1 and v2 -- the Debian
  copyright file is not necessary from a strictly legal point of view.
 
 I don't see the logical justification for this statement.  Our compliance
 with the GPL does not rely on considering source and binary packages as a
 single entity.  The GPL explicitly permits us to treat them as two
 separate entities and distribute the source separately (which is what we
 do).

After reading again point 3 a) of the GPL v1 and v2, I see that I probably
misunderstood what medium customarily used for software interchange
meant.  Sorry for the noise.

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512030419.gc29...@falafel.plessy.net



Accepted lxpolkit 0.1.0-2 (source i386)

2012-05-11 Thread Daniel Baumann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 11 May 2012 07:43:05 +0200
Source: lxpolkit
Binary: lxpolkit lxpolkit-dbg
Architecture: source i386
Version: 0.1.0-2
Distribution: unstable
Urgency: low
Maintainer: Debian LXDE Maintainers lxde-deb...@lists.lxde.org
Changed-By: Daniel Baumann dan...@debian.org
Description: 
 lxpolkit   - LXDE PolicyKit authentication agent
 lxpolkit-dbg - LXDE PolicyKit authentication agent (debug)
Changes: 
 lxpolkit (0.1.0-2) unstable; urgency=low
 .
   * Updating maintainers field to move the package to the LXDE
 maintainers, thanks and welcome Sergey to the team.
   * Updating vcs fields.
   * Adding myself to uploaders.
   * Updating package to debhelper version 9.
   * Updating package to standards version 3.9.3.
   * Making build-depends unversioned where already fulfiled as of
 squeeze.
   * Updating homepage field.
   * Updating copyright file to machine-readable format version 1.0.
   * Rediffing missing-glade.patch with common diff options.
   * Rediffing potfiles-skip.patch with common diff options.
   * Harmonizing rules file.
   * Switching to xz compression for both the source and the binary
 packages.
   * Sorting depends field.
   * Avoiding to repeat the policykit-1 description in the package
 descriptions.
   * Replacing debhelper install file with an override for the install
 destdir in rules.
Checksums-Sha1: 
 12aacfa7f93938f3a11c1dd47e9d1ff412c44379 1377 lxpolkit_0.1.0-2.dsc
 b3d8b112fb2ccb1467654ced22b3f44d5afb6060 154296 lxpolkit_0.1.0.orig.tar.xz
 0fc9a580cab21829ddaea44fdc44b0c5dec59dd3 3408 lxpolkit_0.1.0-2.debian.tar.xz
 c0c99457e5a6fd5f9695dc0a66a90a539ce71c26 2234 lxpolkit_0.1.0-2_i386.deb
 7db5a153ebf8db6efb40a2989def9c0c77ace6df 2278 lxpolkit-dbg_0.1.0-2_i386.deb
Checksums-Sha256: 
 9b93debacc22ac33304b9ace05426880c6a25aa9b671de7ce72e0b61221df523 1377 
lxpolkit_0.1.0-2.dsc
 2c27570c779aa0effaed776b4f22cc0625b4c9919cac1a52b77ce539618723a7 154296 
lxpolkit_0.1.0.orig.tar.xz
 e638122d78684fab275a2ff2bb53d83b02421655d170bb71d40e2f04b9d49d65 3408 
lxpolkit_0.1.0-2.debian.tar.xz
 5dd192771d46564a5cf2d5c0d3cf5ed9837b1a677dd00c9449d71965d0b61a5d 2234 
lxpolkit_0.1.0-2_i386.deb
 2b3d525a09323822fd7fa374ea6f2e8cff4605d054f830ac77d12ff0cdd9a268 2278 
lxpolkit-dbg_0.1.0-2_i386.deb
Files: 
 16df8b9881f55ac4560cbd0099c98cd8 1377 x11 optional lxpolkit_0.1.0-2.dsc
 3d68f06277386a4ac152ace1e950f9ae 154296 x11 optional lxpolkit_0.1.0.orig.tar.xz
 b5bd93f938d0da4ce0e6797d24a77f30 3408 x11 optional 
lxpolkit_0.1.0-2.debian.tar.xz
 c55562299f4c61f9ee7401047e6e82dd 2234 x11 optional lxpolkit_0.1.0-2_i386.deb
 e503ebd52647fd41189902711f84bda6 2278 debug extra lxpolkit-dbg_0.1.0-2_i386.deb

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

iEYEARECAAYFAk+sp0AACgkQ+C5cwEsrK54N7gCgwViEdT7M7hBo8tgTURd9+vIw
V2UAn1W517Mp/O/PG9ZCEQ3zO4TJcf4P
=2dHK
-END PGP SIGNATURE-


Accepted:
lxpolkit-dbg_0.1.0-2_i386.deb
  to main/l/lxpolkit/lxpolkit-dbg_0.1.0-2_i386.deb
lxpolkit_0.1.0-2.debian.tar.xz
  to main/l/lxpolkit/lxpolkit_0.1.0-2.debian.tar.xz
lxpolkit_0.1.0-2.dsc
  to main/l/lxpolkit/lxpolkit_0.1.0-2.dsc
lxpolkit_0.1.0-2_i386.deb
  to main/l/lxpolkit/lxpolkit_0.1.0-2_i386.deb
lxpolkit_0.1.0.orig.tar.xz
  to main/l/lxpolkit/lxpolkit_0.1.0.orig.tar.xz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ssiwu-0003dc...@franck.debian.org



Accepted conky 1.9.0-2 (source all amd64)

2012-05-11 Thread Vincent Cheng
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 09 May 2012 19:27:20 -0700
Source: conky
Binary: conky conky-std conky-cli
Architecture: source all amd64
Version: 1.9.0-2
Distribution: unstable
Urgency: low
Maintainer: Vincent Cheng vincentc1...@gmail.com
Changed-By: Vincent Cheng vincentc1...@gmail.com
Description: 
 conky  - highly configurable system monitor (transitional package)
 conky-cli  - highly configurable system monitor (basic version)
 conky-std  - highly configurable system monitor (default version)
Changes: 
 conky (1.9.0-2) unstable; urgency=low
 .
   * Add debian/patches/fix-kfreebsd-ftbfs.patch to fix FTBFS on kfreebsd.
Checksums-Sha1: 
 c9167ab868d81d3af6d9da3b00e7ed40d6ba0042 2365 conky_1.9.0-2.dsc
 5eb1dc5c6af8bfbb14bed7e11fda8a50c0c95856 18054 conky_1.9.0-2.debian.tar.bz2
 024d3df9f8c61e8f772cde35d5721f8a62c3dd4d 34032 conky_1.9.0-2_all.deb
 1eb2dbb0e76e9c91f322d22ef3ad4cf7b241f0a2 414160 conky-std_1.9.0-2_amd64.deb
 b8bb3ac2a09cb0f6ec44347393b52760f3ca9ea2 261156 conky-cli_1.9.0-2_amd64.deb
Checksums-Sha256: 
 09c72dbdf6a0396c2612c4eb9ab87c5287dfd833a7f2c5bbd16ee968d3cc5c99 2365 
conky_1.9.0-2.dsc
 ddb35ae1d151484863fc03cc7470ce944123d1ddabac23e097235b21b884b499 18054 
conky_1.9.0-2.debian.tar.bz2
 8f400dd1ceb48e95a085de7a6b651f2e4a5e3a7d847b1ae37088b9bc0d4254c2 34032 
conky_1.9.0-2_all.deb
 a2738d90a2e1ddcd88969afe2b4a2b1c5a2686728d0944c0b23cbe51fc8279e6 414160 
conky-std_1.9.0-2_amd64.deb
 e1e70473bc93124b66ed4b68a5ad57900511c6e1cab0187d0bbf427d0e65259f 261156 
conky-cli_1.9.0-2_amd64.deb
Files: 
 cc9b7f9713bf7e746f7b6923b3754b0f 2365 utils optional conky_1.9.0-2.dsc
 2ea5fc383fcd89a5c22fa3576a7bbda6 18054 utils optional 
conky_1.9.0-2.debian.tar.bz2
 7c87979844f1d720ac0aca321f37bc5b 34032 oldlibs extra conky_1.9.0-2_all.deb
 6b2e26eeb951b4de7fe41ef923f3721f 414160 utils optional 
conky-std_1.9.0-2_amd64.deb
 816b4084172774a8de8dc7a12eb40d76 261156 utils optional 
conky-cli_1.9.0-2_amd64.deb

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

iQIcBAEBCAAGBQJPrK59AAoJEDNV9NY7WCHM3wMP/1uXeWtPvf02NMHQFwiusTZz
G62UklJP3aGWhIND9b7DZsi6Jz8TGqpoXobTNgJH5TMqJdiuLTPvXKdR+DbED9aM
ZZh1JNUfgRiL38KO45DGPeuTNezkH0QLfMe9UpTzLAUN2m/r9EPhk+e1mt4tXhWD
XiVQFnLZdKeQEF9+HZ9eeSiIh4mzeL+EfH80xOYMQd4VBM69yORHwPKMCJYek7Hv
Y0VOxFe4TJp1xzOQ6aLXTGA+YihkHw0d9ichFOyVxDamr0EwO9ZCuCrDC0cASQe6
c7QTDbfTER39S1TEpMUGeIwbeH1+7jpFneXZeahQ/20did3ATHkfl4du5P/xH9j4
2pYH0fhIEO0UPo0oPwJ0mvHBiXZ2wfqAWaPWWAkyaM0GXK2hlh1NAltTz0q6JOVc
VRUe4zlCoWpHFOVcyZsTLYYAVO+1JPPTHbT959shACXL7ahatWY7lS0yPaNj8Pv5
wJ847hLR/diI9YQtz02+sxliI4TtWl+K7Q5+IG+4xpG7Li40vDoYMb+Zei7P4Fs4
vd+RAYtcOgXbRfWjUPz9Oh8sRKztWnCwyDiqkY8rjcFDmQv5jb9uKETVMQzTd7lh
SmL8JJLjID9MOMq6WTOj4mUKx55G+izcIbqSXoFxRKQJLb9dI064ncsjtp9qwOdj
pnS4ZZkhwg4Ek34wFJ2f
=KxSm
-END PGP SIGNATURE-


Accepted:
conky-cli_1.9.0-2_amd64.deb
  to main/c/conky/conky-cli_1.9.0-2_amd64.deb
conky-std_1.9.0-2_amd64.deb
  to main/c/conky/conky-std_1.9.0-2_amd64.deb
conky_1.9.0-2.debian.tar.bz2
  to main/c/conky/conky_1.9.0-2.debian.tar.bz2
conky_1.9.0-2.dsc
  to main/c/conky/conky_1.9.0-2.dsc
conky_1.9.0-2_all.deb
  to main/c/conky/conky_1.9.0-2_all.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ssjoj-0005v7...@franck.debian.org



Accepted sitplus 1.0.3-2 (source all amd64)

2012-05-11 Thread Andreas Tille
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 11 May 2012 08:03:06 +0200
Source: sitplus
Binary: sitplus sitplus-data
Architecture: source amd64 all
Version: 1.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Debian Med Packaging Team 
debian-med-packag...@lists.alioth.debian.org
Changed-By: Andreas Tille ti...@debian.org
Description: 
 sitplus- Free software framework for ludic-therapeutic activities
 sitplus-data - Data files for Sitplus, a framework for ludic-therapeutic 
activit
Closes: 672033
Changes: 
 sitplus (1.0.3-2) unstable; urgency=low
 .
   * Work around build failure with GCC 4.7. (Thanks for the patch to
 Matthias Klose d...@debian.org
 Closes: #672033.
   * Debhelper 9 (control+compat)
Checksums-Sha1: 
 8c8d0b454c90f7036cb248c95083b87da07a3e05 1745 sitplus_1.0.3-2.dsc
 9c4f4508c55aa9a3bb2d5ae62bb1904853637788 9607 sitplus_1.0.3-2.debian.tar.gz
 fb335d3ce8540b4962e4596cbc3c2cc25b498065 1218400 sitplus_1.0.3-2_amd64.deb
 8a5af39ff940bfaefd933cd54555d888abb07342 17041554 sitplus-data_1.0.3-2_all.deb
Checksums-Sha256: 
 65194952ab816233dae1247912c011e98b25497a2cd06d37e21a2c1973f3434d 1745 
sitplus_1.0.3-2.dsc
 1d29278e7bc6095d8905971a19eca1f2e6753b4481aed5569187cffa57519aef 9607 
sitplus_1.0.3-2.debian.tar.gz
 92b016176f8f031eba6c18ac067e5fa9590214149449cbdbd99c9b869b0dc200 1218400 
sitplus_1.0.3-2_amd64.deb
 190a20596a4dbe817029bd2790558c43b8ea8ecb71efe7b2e8c90d70080ba7ca 17041554 
sitplus-data_1.0.3-2_all.deb
Files: 
 0a94c20fd21b8716bded960ad55b5a13 1745 misc optional sitplus_1.0.3-2.dsc
 0d0e3f9012b87d66e17d1a47ea9d5c77 9607 misc optional 
sitplus_1.0.3-2.debian.tar.gz
 c00643beb13ca510422d51b2ec491671 1218400 misc optional 
sitplus_1.0.3-2_amd64.deb
 a3faaa4362cc5080fb8773e2f92c2a85 17041554 misc optional 
sitplus-data_1.0.3-2_all.deb

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

iEYEARECAAYFAk+ssRUACgkQYDBbMcCf01p2kgCgkCgaRb8RbtiCs/IpSNfQIz3f
4acAoKdBw10L1hQur82Va35h2a3RSa29
=YdXk
-END PGP SIGNATURE-


Accepted:
sitplus-data_1.0.3-2_all.deb
  to main/s/sitplus/sitplus-data_1.0.3-2_all.deb
sitplus_1.0.3-2.debian.tar.gz
  to main/s/sitplus/sitplus_1.0.3-2.debian.tar.gz
sitplus_1.0.3-2.dsc
  to main/s/sitplus/sitplus_1.0.3-2.dsc
sitplus_1.0.3-2_amd64.deb
  to main/s/sitplus/sitplus_1.0.3-2_amd64.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ssjfw-0006xd...@franck.debian.org



Accepted libgtkada 2.24.1-5 (source all amd64)

2012-05-11 Thread Nicolas Boulenguez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 10 May 2012 23:49:34 +0200
Source: libgtkada
Binary: libgtkada2.24.1-dev libgnomeada2.24.1-dev libgtkglada2.24.1-dev 
libgtkada-dbg libgnomeada-dbg libgtkglada-dbg libgtkada2.24.1 libgnomeada2.24.1 
libgtkglada2.24.1 libgtkada-bin libgtkada-doc
Architecture: source amd64 all
Version: 2.24.1-5
Distribution: unstable
Urgency: low
Maintainer: Ludovic Brenta lbre...@debian.org
Changed-By: Nicolas Boulenguez nicolas.bouleng...@free.fr
Description: 
 libgnomeada-dbg - Ada binding for the GNOME GUI (debugging symbols)
 libgnomeada2.24.1 - Ada binding for the GNOME GUI (dynamic library)
 libgnomeada2.24.1-dev - Ada binding for the GNOME GUI (development files)
 libgtkada-bin - Ada binding for the GTK+ GUI (development utilities)
 libgtkada-dbg - Ada binding for the GTK+ GUI (debugging symbols)
 libgtkada-doc - Ada binding for the GTK+ GUI (documentation)
 libgtkada2.24.1 - Ada binding for the GTK+ GUI (dynamic library)
 libgtkada2.24.1-dev - Ada binding for the GTK+ GUI (development files)
 libgtkglada-dbg - Ada binding for GTK+ OpenGL extensions (debugging symbols)
 libgtkglada2.24.1 - Ada binding for GTK+ OpenGL extensions (dynamic library)
 libgtkglada2.24.1-dev - Ada binding for GTK+ OpenGL extensions (development 
files)
Closes: 669998
Changes: 
 libgtkada (2.24.1-5) unstable; urgency=low
 .
   [Nicolas Boulenguez]
   * rules, *.gpr, ada_libraries: switched to dh_ada_library.
   * rules, control, compat: dh (= 9) should handle build target.
   * control: Standards-Version: 3.9.3 (no changes)
 -dev packages cannot be Multi-Arch: same as they embed a project file
 whose content mentions lib/TRIPLET subdirectories (Closes: #669998).
 -dbg packages can be Multi-Arch: same without Pre-Depends as they do not
 need the linker at install time.
   * rules:
 Standard /usr/share/dpkg/default.mk from dpkg-dev (= 1.16.1)
 Gprbuild now selects gnatgcc instead of gcc automatically.
   * tests: import versioned project, to test both versions in one go.
   * patches/include_only_glib_h: documented.
 .
   [Ludovic Brenta]
   * Build-Depend: dh-ada-library = 2 to avoid a bug affecting gtkada.
Checksums-Sha1: 
 4f329797973e55ae50252402ff883372527ca146 2245 libgtkada_2.24.1-5.dsc
 e80ac9a24a77308f19cc6fe200afba1fec7b4c31 23372 
libgtkada_2.24.1-5.debian.tar.bz2
 6f4ec7c81d92a4fd195556ddea31cadb924ad515 8211672 
libgtkada2.24.1-dev_2.24.1-5_amd64.deb
 b9fddb1921d6a4d835a66ef5ba913b2286ae5b8e 738174 
libgnomeada2.24.1-dev_2.24.1-5_amd64.deb
 65b60d047be364458b6e4b69c1ed64ac006b64aa 162316 
libgtkglada2.24.1-dev_2.24.1-5_amd64.deb
 3de6436660e4148bdb1914eb60ef7ae25a8758ec 2560162 
libgtkada-dbg_2.24.1-5_amd64.deb
 e27b157cbf86b56197c3c54a5223df4c627c3d4f 216948 
libgnomeada-dbg_2.24.1-5_amd64.deb
 c5b507cb822ae6151af42104e813c4b34e56b871 62464 
libgtkglada-dbg_2.24.1-5_amd64.deb
 c839fc7246d7107b2be87462fc9cf8201bd4fb36 1302388 
libgtkada2.24.1_2.24.1-5_amd64.deb
 d9119acfcf82db7cf4522d632867e332ca30348e 102614 
libgnomeada2.24.1_2.24.1-5_amd64.deb
 1b40ac935e2c21c3c0f235e9119407fad6690c82 33032 
libgtkglada2.24.1_2.24.1-5_amd64.deb
 b93bb7d18d45d43baf2153f6603051c1dc2d3b2d 15200 libgtkada-bin_2.24.1-5_amd64.deb
 cb05f0dce25bca16624fef853efee306ad07fe11 422 libgtkada-doc_2.24.1-5_all.deb
Checksums-Sha256: 
 b8511908d923fab30d31a8754d214105552065cc66cf85225b280f03388bd7ed 2245 
libgtkada_2.24.1-5.dsc
 1d5d326d81bfffb558e88895e698fc820a1cacfaca1296a5b8c420f320694ee5 23372 
libgtkada_2.24.1-5.debian.tar.bz2
 b1bc86ebecf1c73855cf281dd88b204c1d900f47301d4e6c5602a8c457cb0c79 8211672 
libgtkada2.24.1-dev_2.24.1-5_amd64.deb
 3650965bd9eae46ade895854efbf99f4a629eea74d882d36c3d7f82556303384 738174 
libgnomeada2.24.1-dev_2.24.1-5_amd64.deb
 aeadfe1e4c7786b8ec61bd50a4cd8bcf7962c742b3acad5763d4e165efd0a53f 162316 
libgtkglada2.24.1-dev_2.24.1-5_amd64.deb
 42859ffb60176eae462a394d7a4605513bb7b0e910e2fdb77a3ebe5a74c0a159 2560162 
libgtkada-dbg_2.24.1-5_amd64.deb
 82f240d73031c53db1c8ee2ad87f6f43371da51827ebdf2f8e035513eb677015 216948 
libgnomeada-dbg_2.24.1-5_amd64.deb
 d8fbc52ced7e48c4920725320ac036cc740dc22f42545eac9a0f9890034c3b2b 62464 
libgtkglada-dbg_2.24.1-5_amd64.deb
 0022dd33ca690bcf2d82682170af68a88d2d9e79d1390c8f403792e5ed22ae6b 1302388 
libgtkada2.24.1_2.24.1-5_amd64.deb
 dfdd1541648160af42303017d0f921b2498788198f94d50271ad98314db4f4e6 102614 
libgnomeada2.24.1_2.24.1-5_amd64.deb
 1e25760fbc5103d4200f5202a7c1de9718e9a3a6ced7160becd8182a63cf0a25 33032 
libgtkglada2.24.1_2.24.1-5_amd64.deb
 5db0db1e9207c15a2c2fb8b07e330f1f94b872fc58cb9838be04daee9345a6f9 15200 
libgtkada-bin_2.24.1-5_amd64.deb
 1b9c8b2214f6c96f88d86676e05d3d1a2a3ad6f6057f3f1e61579efffd57bd9b 422 
libgtkada-doc_2.24.1-5_all.deb
Files: 
 81be1f1fcd64cbf5cb0238f94f2f959c 2245 libs optional libgtkada_2.24.1-5.dsc
 fb2f3f951ea86c6bff3c77cd606d941d 23372 libs optional 
libgtkada_2.24.1-5.debian.tar.bz2
 7fa272c577f8edecaf839e9f6268a658 8211672 libdevel optional 

Accepted smarty-gettext 1.0b1-6 (source all)

2012-05-11 Thread Mike Gabriel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 10 May 2012 20:49:21 +0200
Source: smarty-gettext
Binary: smarty-gettext
Architecture: source all
Version: 1.0b1-6
Distribution: unstable
Urgency: low
Maintainer: Mike Gabriel mike.gabr...@das-netzwerkteam.de
Changed-By: Mike Gabriel mike.gabr...@das-netzwerkteam.de
Description: 
 smarty-gettext - Gettext plugin enabling internationalization in Smarty
Changes: 
 smarty-gettext (1.0b1-6) unstable; urgency=low
 .
   * New maintainer.
Checksums-Sha1: 
 586ebf600a2552393428ea0b2353a8f5993f19c8 1952 smarty-gettext_1.0b1-6.dsc
 a359f98533a5a7e8201e56524cd9efc66d94138a 2104 
smarty-gettext_1.0b1-6.debian.tar.gz
 e02416ba7046af7bfcf70e548e466d5fbbda97fa 8786 smarty-gettext_1.0b1-6_all.deb
Checksums-Sha256: 
 080ac2e7d6423b22389249ff59f73f11597fc7d9fcff1e0dd94374e2e282392b 1952 
smarty-gettext_1.0b1-6.dsc
 a6fdc6640041f2c8c91088fc9d1a4445e17edf2a6dac2f4094b296eb1a1a5f5e 2104 
smarty-gettext_1.0b1-6.debian.tar.gz
 0a87d67b9fe2eb227fc9e8f416301f97d1c47bab6092e1c30db629bb42b04f70 8786 
smarty-gettext_1.0b1-6_all.deb
Files: 
 c3f351a7891ecb7c70566d776dcaf34a 1952 web optional smarty-gettext_1.0b1-6.dsc
 9a1715bf397622583a34a4ae52d25af2 2104 web optional 
smarty-gettext_1.0b1-6.debian.tar.gz
 6facb21b741e309a43c67e8a5b661c44 8786 web optional 
smarty-gettext_1.0b1-6_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Signed by Raphael Hertzog

iQIcBAEBCAAGBQJPrMKjAAoJEOYZBF3yrHKas4cP/jNDSxF59udGgZBxJaVHpW1z
Ov98MzarjHXm0cJWS0wBjMnVRyvxaxNwwuob17Di3aje6h3emKzFe57MIHGMFicH
9PFv/hTCpmoaq6jf8ITjoDV1paiVXmJ51Y93np9j3V0ip3bPTHdrrSmtHYidE6uA
8u0P7WvVYWDu1WW4jyC2TST13EQMxG7lEr6AKPkUbpd3l9JAPtMiMNfiXcFuiVww
jfkH5wUfg+4o+vtK57AAOMpSs/BM1eMnFy6ep8iuJZ+qg4LbP2fUdTnKCn/Mup2d
jgHNt349+bF1JNbivcBdAWc1yAZJFkeEt2VajjV16jkJh6r3ekE9oglyV9XCeUd9
aWgtX39Jt6x02LMPFSnC4cV7lZ+MBdjN5RJREmKX4C5oQdLmvX3RjVJZKYfNyOoP
lwcryiSjhUal37tp5fZiKRaYG6iHruqyiE1G9VTDWmxxgYAqg4ASw9YbLuxMzW7V
vidlOYiZmXVonkqELez+Qw68QMU6JIZ3CgWoc9IkBOcATH4IF+IKywHzpLXhq+er
XTTiFpr9dROx7oUJkZbsssaNVmwbC3hL2xLrwFOX6ixzQmtkKO50Cxw+ISAri+1A
VO0CwKNwZa9QSjM7sTQAJ978NFAJ5mZjVZAx5WyHAzs3djzTT5VUa27vyBomnmty
JnxZIexgQ2chVjg/QRIN
=NUwf
-END PGP SIGNATURE-


Accepted:
smarty-gettext_1.0b1-6.debian.tar.gz
  to main/s/smarty-gettext/smarty-gettext_1.0b1-6.debian.tar.gz
smarty-gettext_1.0b1-6.dsc
  to main/s/smarty-gettext/smarty-gettext_1.0b1-6.dsc
smarty-gettext_1.0b1-6_all.deb
  to main/s/smarty-gettext/smarty-gettext_1.0b1-6_all.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sskio-00047w...@franck.debian.org



Accepted db 5.1.29-2 (source all amd64)

2012-05-11 Thread Ondřej Surý
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 11 May 2012 10:10:08 +0200
Source: db
Binary: db5.1-doc libdb5.1-dev libdb5.1 db5.1-util db5.1-sql-util libdb5.1++ 
libdb5.1++-dev libdb5.1-tcl libdb5.1-dbg libdb5.1-java-jni libdb5.1-java 
libdb5.1-java-gcj libdb5.1-java-dev libdb5.1-sql-dev libdb5.1-sql 
libdb5.1-stl-dev libdb5.1-stl
Architecture: source all amd64
Version: 5.1.29-2
Distribution: unstable
Urgency: low
Maintainer: Debian Berkeley DB Group pkg-db-de...@lists.alioth.debian.org
Changed-By: Ondřej Surý ond...@debian.org
Description: 
 db5.1-doc  - Berkeley v5.1 Database Documentation [html]
 db5.1-sql-util - Berkeley v5.1 SQL Database Utilities
 db5.1-util - Berkeley v5.1 Database Utilities
 libdb5.1   - Berkeley v5.1 Database Libraries [runtime]
 libdb5.1++ - Berkeley v5.1 Database Libraries for C++ [runtime]
 libdb5.1++-dev - Berkeley v5.1 Database Libraries for C++ [development]
 libdb5.1-dbg - Berkeley v5.1 Database Libraries [debug]
 libdb5.1-dev - Berkeley v5.1 Database Libraries [development]
 libdb5.1-java - Berkeley v5.1 Database Libraries for Java
 libdb5.1-java-dev - Berkeley v5.1 Database Libraries for Java [development]
 libdb5.1-java-gcj - Berkeley v5.1 Database Libraries for Java (native code)
 libdb5.1-java-jni - Berkeley v5.1 Database Libraries for Java
 libdb5.1-sql - Berkeley v5.1 Database Libraries [SQL runtime]
 libdb5.1-sql-dev - Berkeley v5.1 Database Libraries [SQL development]
 libdb5.1-stl - Berkeley v5.1 Database Libraries [STL runtime]
 libdb5.1-stl-dev - Berkeley v5.1 Database Libraries [STL development]
 libdb5.1-tcl - Berkeley v5.1 Database Libraries for Tcl [module]
Closes: 670011
Changes: 
 db (5.1.29-2) unstable; urgency=low
 .
   * Split libdb5.1-java to arch independent libdb5.1-java and move JNI
 libraries to libdb5.1-java-jni (Closes: #670011)
Checksums-Sha1: 
 d71a7aa79804dfa3f928936eb3ecb72155d9bad0 2118 db_5.1.29-2.dsc
 cc119449f82af1071c828efd046d38ca985ed3b3 28242 db_5.1.29-2.debian.tar.gz
 1b15cfe36a27b30fabb5df440a06a97e4bc7300e 17311544 db5.1-doc_5.1.29-2_all.deb
 7b7d5276eb03d35a81921359fdcfe64ffa939917 881574 libdb5.1-dev_5.1.29-2_amd64.deb
 76dbbeb1f7bcc7b22d049bd67c47c4b8ac535b66 722688 libdb5.1_5.1.29-2_amd64.deb
 fe9616612c7a81eead78d769daf7df611434c70f 87426 db5.1-util_5.1.29-2_amd64.deb
 71d04b8c53dfc5c3a1b7ef703c48b86ffa101589 22024 
db5.1-sql-util_5.1.29-2_amd64.deb
 67432de6f90ba2210203471a93e7c65be7e8ec65 756738 libdb5.1++_5.1.29-2_amd64.deb
 4cd6322aaef64440d87cc90183836ca604a7a4ae 1802322 
libdb5.1++-dev_5.1.29-2_amd64.deb
 f9fc7312f4d5e98986a803e4d82d951a33f0ee9d 2695252 
libdb5.1-tcl_5.1.29-2_amd64.deb
 f9450a29bc8542cd54e8e4946364859032e4b0ec 28004872 
libdb5.1-dbg_5.1.29-2_amd64.deb
 5c57762dd60e64eabce094ae50b58cea9a6ed6bc 526192 
libdb5.1-java_5.1.29-2_amd64.deb
 de5b2cffeb6a364ee35921e24ff8d7d923568548 798640 
libdb5.1-java-gcj_5.1.29-2_amd64.deb
 9e8cccf4cd9b3e1e8fb81778f038b09b7c82c251 904498 
libdb5.1-java-dev_5.1.29-2_amd64.deb
 38cce64effb1e2195f4fc2fe4a4d996148e55115 2305744 
libdb5.1-sql-dev_5.1.29-2_amd64.deb
 1ba39ba5aae490a1456f3e691fcb0d0b895de111 959630 libdb5.1-sql_5.1.29-2_amd64.deb
 9f1f49acd45313b63309af8144fb5d648222bf29 1963554 
libdb5.1-stl-dev_5.1.29-2_amd64.deb
 399c0061842ba82009603f01d3482d6455710ecb 786002 libdb5.1-stl_5.1.29-2_amd64.deb
Checksums-Sha256: 
 5911e40b2eb6a0e923a8cb62131c2b2c2e55f581f78510e21940bf7d43979e73 2118 
db_5.1.29-2.dsc
 e937bd9ad94e5d73870a9e70d7db575aa2a4a7b087dd92aadf538851127b9e38 28242 
db_5.1.29-2.debian.tar.gz
 a174a5b46d5838554c47c79e8ba7136449e2ec2953f54b6a8d0ff62f68ade2d7 17311544 
db5.1-doc_5.1.29-2_all.deb
 5696d277dfea0d19ac581fcebfb8e9882d1b36130579ef9bc8488244f54729d5 881574 
libdb5.1-dev_5.1.29-2_amd64.deb
 77e3b77bd6a998693eb12bb7d9f1a572b130a520e26ee8a09c1669b8b25d9656 722688 
libdb5.1_5.1.29-2_amd64.deb
 8c4f824e91fee0afbdd12b4ca6fbf2dba8c4d8d76206a11f11ed029b75678444 87426 
db5.1-util_5.1.29-2_amd64.deb
 e40f156562581d4e97ec70872929d002e2c3e64d800775cedfb47f4108d18f69 22024 
db5.1-sql-util_5.1.29-2_amd64.deb
 a678b302ee2f264f633dee47fe8408f92bfe54a754b122f6d30ec2c24d2909ea 756738 
libdb5.1++_5.1.29-2_amd64.deb
 97e5763ae71ba9e70552643a3f24155033b4507c0fb256e399ccdbabdc1e4ede 1802322 
libdb5.1++-dev_5.1.29-2_amd64.deb
 c0291d711923276b46ac054f721aa55b65a3767371f1ab4bfbbd81d451461685 2695252 
libdb5.1-tcl_5.1.29-2_amd64.deb
 746c597d9810b5467d2d59f777f0e81597b385803b72ae22ee8c16ed0ad9d8aa 28004872 
libdb5.1-dbg_5.1.29-2_amd64.deb
 ad198c00f2578c523ddee0c6cd38cc6f4b6c21dd54dc2de8d6663cdd759ab93e 526192 
libdb5.1-java_5.1.29-2_amd64.deb
 7cf6cd285c4813ab79c5c98a1177b88ef0dae4baeef56ea126b8317cfe73100b 798640 
libdb5.1-java-gcj_5.1.29-2_amd64.deb
 093815f7e8bd24697a11d6fe68c76e1697aca6c2572df1f166a0a5fa957ea2ca 904498 
libdb5.1-java-dev_5.1.29-2_amd64.deb
 e812eedd48299b9a567b3f8038e82d09ba44ad77909447d0bba3c972dd7d7f9c 2305744 
libdb5.1-sql-dev_5.1.29-2_amd64.deb
 8f563459e4efd5e5e25f8d2d95da6d50fe03687a3314648c89b6a3c944a0d9f0 959630 

Accepted libiscsi 1.4.0-1 (source i386)

2012-05-11 Thread Michael Tokarev
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Fri, 04 May 2012 12:05:48 +0400
Source: libiscsi
Binary: libiscsi1 libiscsi-dev libiscsi-bin
Architecture: source i386
Version: 1.4.0-1
Distribution: unstable
Urgency: low
Maintainer: Michael Tokarev m...@tls.msk.ru
Changed-By: Michael Tokarev m...@tls.msk.ru
Description: 
 libiscsi-bin - iSCSI client shared library - utilities
 libiscsi-dev - iSCSI client shared library
 libiscsi1  - iSCSI client shared library
Changes: 
 libiscsi (1.4.0-1) unstable; urgency=low
 .
   * new upstream version
   * build-depend on debhelper  9~
   * update Standards-Version to 3.9.3 (no changes needed)
Checksums-Sha1: 
 90f54a3a82cab6425cc2193fe771e97ad36f0722 1306 libiscsi_1.4.0-1.dsc
 ab337f6d5236c4cec54027cae2a9ce16b8e5a432 98937 libiscsi_1.4.0.orig.tar.gz
 a9e7fc64f4a7f6c66f5ecd0dadffdfd27b5cf772 2354 libiscsi_1.4.0-1.debian.tar.gz
 be7a426f05d0b8ac60e5ff785ad5aeb2cdaf35fb 39860 libiscsi1_1.4.0-1_i386.deb
 c8561b2e83da11dc14107fffb4a1c6a675198a32 48660 libiscsi-dev_1.4.0-1_i386.deb
 c7ba28ffb95c21d9b99acae780d0eabb575b0e7a 11308 libiscsi-bin_1.4.0-1_i386.deb
Checksums-Sha256: 
 16dba5af11294a3d03a871b3290ba2c463742805344d50e14615b2f364cb4d95 1306 
libiscsi_1.4.0-1.dsc
 87eaa197f7d5420d5d0deed65ae0814ee79e31f732ee81e006b06365d62298c8 98937 
libiscsi_1.4.0.orig.tar.gz
 9b16a234568767d7a52956d52bfb0682c9963b5e930db1ad2a3d0eb32730d59f 2354 
libiscsi_1.4.0-1.debian.tar.gz
 358f3aae57db961e943b7f30a639dbdb001ee80301e8d729d1fcc6da8bd396cf 39860 
libiscsi1_1.4.0-1_i386.deb
 8929f10d0bf796f7c8421a1e0437b0a5fcdf50f33e3cf4ffa5f8d886ca269601 48660 
libiscsi-dev_1.4.0-1_i386.deb
 89f4d50a517b1c5a875253c551952a3725ec80c8d0d59e9d01b91d25cbf73636 11308 
libiscsi-bin_1.4.0-1_i386.deb
Files: 
 6eb1a335eb63ddf80ccba0204e6b0c8f 1306 net optional libiscsi_1.4.0-1.dsc
 19abf4e40e95c521f473ce8a26479282 98937 net optional libiscsi_1.4.0.orig.tar.gz
 fe3731872e851cc5ddbe835b681ad230 2354 net optional 
libiscsi_1.4.0-1.debian.tar.gz
 0b34e6aab14c3daf61e77364741a8616 39860 libs optional libiscsi1_1.4.0-1_i386.deb
 50678d0c7c2a7a264a94f7af822a5389 48660 libdevel optional 
libiscsi-dev_1.4.0-1_i386.deb
 522a53d1fc9469f64e21124ab8f061d4 11308 net optional 
libiscsi-bin_1.4.0-1_i386.deb

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

iJwEAQECAAYFAk+szWUACgkQUlPFrXTwyDgyWAP9HYO7aWSPkbOmyjEdvVtjDJpu
ZyePGrl4lXhhT2h6lDgNA0D7MzYwBnnQUhdZ7DxX0GQ6bMQ2Za/96bDEXVLoWqya
6pbk9j3ngrW9BePuJ+n6iKBqtZ8FSo4cBZk1r/FORRbMKiyLghQ4sdgWpygCSkgY
xaj7whdYU1ryVEOsaNc=
=h4jK
-END PGP SIGNATURE-


Accepted:
libiscsi-bin_1.4.0-1_i386.deb
  to main/libi/libiscsi/libiscsi-bin_1.4.0-1_i386.deb
libiscsi-dev_1.4.0-1_i386.deb
  to main/libi/libiscsi/libiscsi-dev_1.4.0-1_i386.deb
libiscsi1_1.4.0-1_i386.deb
  to main/libi/libiscsi/libiscsi1_1.4.0-1_i386.deb
libiscsi_1.4.0-1.debian.tar.gz
  to main/libi/libiscsi/libiscsi_1.4.0-1.debian.tar.gz
libiscsi_1.4.0-1.dsc
  to main/libi/libiscsi/libiscsi_1.4.0-1.dsc
libiscsi_1.4.0.orig.tar.gz
  to main/libi/libiscsi/libiscsi_1.4.0.orig.tar.gz


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sslv6-ea...@franck.debian.org



Accepted lua-cgi 5.1.4+dfsg-2 (source all)

2012-05-11 Thread Enrico Tassi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Tue, 01 May 2012 11:45:05 +0200
Source: lua-cgi
Binary: lua-cgi liblua5.1-cgi0 liblua5.1-cgi-dev
Architecture: source all
Version: 5.1.4+dfsg-2
Distribution: unstable
Urgency: low
Maintainer: Enrico Tassi gareuselesi...@debian.org
Changed-By: Enrico Tassi gareuselesi...@debian.org
Description: 
 liblua5.1-cgi-dev - Transitional package for lua-cgi
 liblua5.1-cgi0 - Transitional package for lua-cgi
 lua-cgi- CGI library for the Lua language
Changes: 
 lua-cgi (5.1.4+dfsg-2) unstable; urgency=low
 .
   * Update dependency on liblua5.1-socket2 - lua-socket
Checksums-Sha1: 
 d533ff8ccbfb3eaf6ca31f3f31667f37af534f29 1347 lua-cgi_5.1.4+dfsg-2.dsc
 188bd3527705946b391f05e9c496a88ede3ab857 5115 
lua-cgi_5.1.4+dfsg-2.debian.tar.gz
 15d58a00daf0cb80ffc8e27ae3cda1abfc7286a1 133236 lua-cgi_5.1.4+dfsg-2_all.deb
 0e517e2fdc16be5ea39fd82fb557676aa049ca41 3010 
liblua5.1-cgi0_5.1.4+dfsg-2_all.deb
 2e96cc30d06d59eb85d56c1dff4d1b284006d598 3010 
liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb
Checksums-Sha256: 
 4e3f2ccbcd31978103bc03b18abca14e8c04fa157e2a22cf546e62086475133d 1347 
lua-cgi_5.1.4+dfsg-2.dsc
 02467ebf977315954314d08665b679a32ad43caf9103bccc18c2a7b9735fb66e 5115 
lua-cgi_5.1.4+dfsg-2.debian.tar.gz
 3543849ea569be3935fefcad82bbabce457076f935ae7d5e5c81ff06511f7b8a 133236 
lua-cgi_5.1.4+dfsg-2_all.deb
 6b0eb6db6dc311c295bf6a9ec53eb99ab6e0ecc19e435ebe1aea6dad19578b1d 3010 
liblua5.1-cgi0_5.1.4+dfsg-2_all.deb
 fa4d5e7309e7e1b9adb107606e3f563dc5cd0765985cd57dc79a8d60b8545b56 3010 
liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb
Files: 
 7846ed72ebdc46fd2094a544fa47bf7c 1347 interpreters optional 
lua-cgi_5.1.4+dfsg-2.dsc
 06bf0bf533c865c0a20d6f6e79075bd2 5115 interpreters optional 
lua-cgi_5.1.4+dfsg-2.debian.tar.gz
 3edfd753b7e39cb7fd4a89e6a48cd45f 133236 interpreters optional 
lua-cgi_5.1.4+dfsg-2_all.deb
 763d8136b134b88d07891044004595d0 3010 oldlibs extra 
liblua5.1-cgi0_5.1.4+dfsg-2_all.deb
 3da1f49578bf8cffb9ede7e426cf9254 3010 oldlibs extra 
liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb

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

iEYEARECAAYFAk+sw28ACgkQ7kkcPgEj8vKDCgCffF24gSWVlJwDq2GLJjgQ770U
KpoAoKCSdxUSZJTen3WBQBPgXozrkPwZ
=8wom
-END PGP SIGNATURE-


Accepted:
liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb
  to main/l/lua-cgi/liblua5.1-cgi-dev_5.1.4+dfsg-2_all.deb
liblua5.1-cgi0_5.1.4+dfsg-2_all.deb
  to main/l/lua-cgi/liblua5.1-cgi0_5.1.4+dfsg-2_all.deb
lua-cgi_5.1.4+dfsg-2.debian.tar.gz
  to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2.debian.tar.gz
lua-cgi_5.1.4+dfsg-2.dsc
  to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2.dsc
lua-cgi_5.1.4+dfsg-2_all.deb
  to main/l/lua-cgi/lua-cgi_5.1.4+dfsg-2_all.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sslvf-q1...@franck.debian.org



Accepted lua-copas 1.1.6-5 (source all)

2012-05-11 Thread Enrico Tassi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Thu, 03 May 2012 20:49:47 +0200
Source: lua-copas
Binary: lua-copas liblua5.1-copas0 liblua5.1-copas-dev
Architecture: source all
Version: 1.1.6-5
Distribution: unstable
Urgency: low
Maintainer: Enrico Tassi gareuselesi...@debian.org
Changed-By: Enrico Tassi gareuselesi...@debian.org
Description: 
 liblua5.1-copas-dev - Transitional package for lua-copas
 liblua5.1-copas0 - Transitional package for lua-copas
 lua-copas  - Copas is a dispatcher of concurrent TCP/IP requests
Changes: 
 lua-copas (1.1.6-5) unstable; urgency=low
 .
   * Update depends on liblua5.1-socket2 - lua-socket
Checksums-Sha1: 
 62cd3ea77d7a3dd30113694dd67965613ad9cdd1 1342 lua-copas_1.1.6-5.dsc
 24135fc383f749302a608871a2cf180fef07b02e 2809 lua-copas_1.1.6-5.debian.tar.gz
 8e9a1e5149190489321abf43f9ec564faa0783a0 25246 lua-copas_1.1.6-5_all.deb
 ac194a2b32ce83165b04cb9ce5a49ca8c828d3a1 2666 liblua5.1-copas0_1.1.6-5_all.deb
 c66609a8e7b996eac9c3aff62d94f9c82d4fef22 2670 
liblua5.1-copas-dev_1.1.6-5_all.deb
Checksums-Sha256: 
 ad91a1d62100fa55ce74efe212d3d95178503ecd00505134aab0bdd57c51368a 1342 
lua-copas_1.1.6-5.dsc
 03a530d9fe104bddbe3e32660d78b45b0ebebc12dcd472bf7e61b69fc60021f7 2809 
lua-copas_1.1.6-5.debian.tar.gz
 df5790afc9487a3ff6579c13fc20184ffd36bffd9145c8bde1a52bed66cfda3d 25246 
lua-copas_1.1.6-5_all.deb
 4529b3a91ae3b4ad0bef2f09db30445d208feb67fd7e78d6ce3836311e7a07bc 2666 
liblua5.1-copas0_1.1.6-5_all.deb
 7fcd51921a3d231cb993ec824cd7f8e8caa95e6af64f0102f01e6b94f558fa59 2670 
liblua5.1-copas-dev_1.1.6-5_all.deb
Files: 
 571aad75d9890fd0b1e446f25fbebc2e 1342 interpreters optional 
lua-copas_1.1.6-5.dsc
 320e05a78e9cea5b118d3963e2663d79 2809 interpreters optional 
lua-copas_1.1.6-5.debian.tar.gz
 175f32bd1f8be444122e71b2f00f2114 25246 interpreters optional 
lua-copas_1.1.6-5_all.deb
 45f52de922a9a98abf42f1cb8f5c44b7 2666 oldlibs extra 
liblua5.1-copas0_1.1.6-5_all.deb
 0f95e7a2ee88f26a7916659c5aa855ba 2670 oldlibs extra 
liblua5.1-copas-dev_1.1.6-5_all.deb

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

iEYEARECAAYFAk+sxg4ACgkQ7kkcPgEj8vJYAgCgt+3PndfZQgrzpYbMaeJdnwfG
xVUAoJZpAPG06YU9F7ShYFg0uK2ydJdq
=A3Se
-END PGP SIGNATURE-


Accepted:
liblua5.1-copas-dev_1.1.6-5_all.deb
  to main/l/lua-copas/liblua5.1-copas-dev_1.1.6-5_all.deb
liblua5.1-copas0_1.1.6-5_all.deb
  to main/l/lua-copas/liblua5.1-copas0_1.1.6-5_all.deb
lua-copas_1.1.6-5.debian.tar.gz
  to main/l/lua-copas/lua-copas_1.1.6-5.debian.tar.gz
lua-copas_1.1.6-5.dsc
  to main/l/lua-copas/lua-copas_1.1.6-5.dsc
lua-copas_1.1.6-5_all.deb
  to main/l/lua-copas/lua-copas_1.1.6-5_all.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sslvw-xa...@franck.debian.org



Accepted lua-svn 0.4.0-6 (source all amd64)

2012-05-11 Thread Enrico Tassi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Format: 1.8
Date: Mon, 30 Apr 2012 13:08:21 +0200
Source: lua-svn
Binary: lua-svn lua-svn-dev liblua5.1-svn1 liblua5.1-svn-dev
Architecture: source amd64 all
Version: 0.4.0-6
Distribution: unstable
Urgency: low
Maintainer: Enrico Tassi gareuselesi...@debian.org
Changed-By: Enrico Tassi gareuselesi...@debian.org
Description: 
 liblua5.1-svn-dev - Transitional package for lua-svn-dev
 liblua5.1-svn1 - Transitional package for lua-svn
 lua-svn- Subversion library for the Lua language
 lua-svn-dev - Development files for the Subversion library for the Lua language
Changes: 
 lua-svn (0.4.0-6) unstable; urgency=low
 .
   * Update depends on liblua5.1-socket2 - lua-socket
Checksums-Sha1: 
 88ee598f5bc88e8228a86e99f8d62747f918c42b 1434 lua-svn_0.4.0-6.dsc
 2df72eeaed7f48257a206725ac8e291ee1c1d6c7 4220 lua-svn_0.4.0-6.debian.tar.gz
 5a0a6e2952e2b9adf8fcc1146302ddd9eefa0d3e 17362 lua-svn_0.4.0-6_amd64.deb
 b217f592c9f5cf17ec753ae09a3131faa4a5 23234 lua-svn-dev_0.4.0-6_amd64.deb
 e341ada50f8346ec1dea0a7f9eb9f4f10f0e4263 3024 liblua5.1-svn1_0.4.0-6_all.deb
 1924b0fb2f9490a20110b2575646c057b3b239e6 3030 liblua5.1-svn-dev_0.4.0-6_all.deb
Checksums-Sha256: 
 81cb7c3c6c0b7a50ddcaa798020cd954e08b7f7dd730042c691b4d738bd4929f 1434 
lua-svn_0.4.0-6.dsc
 663105cfba2c52f88f63f8bbdc2b4a9fc14b344b0e8ed4d8519f52b6a4fafa2f 4220 
lua-svn_0.4.0-6.debian.tar.gz
 942652048757a55b455881e2818d7b13985ef4fcaa0fd7a331f10cb443a3c4b0 17362 
lua-svn_0.4.0-6_amd64.deb
 96b7e159bc40a58d60cf4af4c2942687c734103e74384a428ebe86b016c23806 23234 
lua-svn-dev_0.4.0-6_amd64.deb
 210086af89a6a2806dea4536b0aabce109f78798d6c168879b01623305fc37ab 3024 
liblua5.1-svn1_0.4.0-6_all.deb
 3b7a20aa68bdb4b5da2538ac7f904a5a3bfb9f4c72d9d030eebde8c7ed95f764 3030 
liblua5.1-svn-dev_0.4.0-6_all.deb
Files: 
 5a441c1b19b6620b8d01dc484739c397 1434 interpreters optional lua-svn_0.4.0-6.dsc
 a36e0bbffe48c130a20c81edb2fd 4220 interpreters optional 
lua-svn_0.4.0-6.debian.tar.gz
 7f4d64647e15dc52e9c4a168b5e035ae 17362 interpreters optional 
lua-svn_0.4.0-6_amd64.deb
 fdd51b6412c37d2a77100be6f23f458f 23234 libdevel optional 
lua-svn-dev_0.4.0-6_amd64.deb
 c5954229ae260b84a43bf53940574ce2 3024 oldlibs extra 
liblua5.1-svn1_0.4.0-6_all.deb
 6cd65626cee4a0283418cc2f8b47112e 3030 oldlibs extra 
liblua5.1-svn-dev_0.4.0-6_all.deb

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

iEYEARECAAYFAk+sxXkACgkQ7kkcPgEj8vJb3wCgpI3ecg4qFKDqkmK99E6it3mw
4RIAnjiK+2CQMsGHtKqSvZEMfi8LIBrs
=Xui1
-END PGP SIGNATURE-


Accepted:
liblua5.1-svn-dev_0.4.0-6_all.deb
  to main/l/lua-svn/liblua5.1-svn-dev_0.4.0-6_all.deb
liblua5.1-svn1_0.4.0-6_all.deb
  to main/l/lua-svn/liblua5.1-svn1_0.4.0-6_all.deb
lua-svn-dev_0.4.0-6_amd64.deb
  to main/l/lua-svn/lua-svn-dev_0.4.0-6_amd64.deb
lua-svn_0.4.0-6.debian.tar.gz
  to main/l/lua-svn/lua-svn_0.4.0-6.debian.tar.gz
lua-svn_0.4.0-6.dsc
  to main/l/lua-svn/lua-svn_0.4.0-6.dsc
lua-svn_0.4.0-6_amd64.deb
  to main/l/lua-svn/lua-svn_0.4.0-6_amd64.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1sslwh-ge...@franck.debian.org



Accepted nvidia-cuda-toolkit 4.2.9-1 (source all amd64 i386)

2012-05-11 Thread Andreas Beckmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 11 May 2012 10:32:07 +0200
Source: nvidia-cuda-toolkit
Binary: nvidia-cuda-toolkit nvidia-cuda-doc nvidia-cuda-gdb 
nvidia-visual-profiler nvidia-cuda-dev nvidia-opencl-dev libcudart4 libcublas4 
libcufft4 libcusparse4 libcurand4 libnpp4 libcuinj4 libcupti4 libcupti-dev 
libcupti-doc
Architecture: all amd64 i386 source
Version: 4.2.9-1
Distribution: unstable
Urgency: low
Maintainer: Debian NVIDIA Maintainers pkg-nvidia-de...@lists.alioth.debian.org
Changed-By: Andreas Beckmann deb...@abeckmann.de
Description: 
 libcublas4 - NVIDIA CUDA BLAS runtime library
 libcudart4 - NVIDIA CUDA runtime library
 libcufft4  - NVIDIA CUDA FFT runtime library
 libcuinj4  - NVIDIA CUDA INJ runtime library
 libcupti-dev - NVIDIA CUDA Profiler Tools Interface development files
 libcupti-doc - NVIDIA CUDA Profiler Tools Interface documentation
 libcupti4  - NVIDIA CUDA Profiler Tools Interface runtime library
 libcurand4 - NVIDIA CUDA Random Numbers Generation runtime library
 libcusparse4 - NVIDIA CUDA Sparse Matrix runtime library
 libnpp4- NVIDIA Performance Primitives runtime library
 nvidia-cuda-dev - NVIDIA CUDA development files
 nvidia-cuda-doc - NVIDIA CUDA and OpenCL documentation
 nvidia-cuda-gdb - NVIDIA CUDA GDB
 nvidia-cuda-toolkit - NVIDIA CUDA toolkit
 nvidia-opencl-dev - NVIDIA OpenCL development files
 nvidia-visual-profiler - NVIDIA Visual Profiler
Changes: 
 nvidia-cuda-toolkit (4.2.9-1) unstable; urgency=low
 .
   * New upstream release 4.2 (April 2012).
   * New download URL: http://developer.nvidia.com/cuda-downloads
   * Update symbols files.
   * debian/copyright: Update NVIDIA license.
   * The toolkit now supports GCC 4.6 (but nothing newer).  Add g++-4.6 and
 gcc-4.6 as preferred alternative dependencies.
Checksums-Sha1: 
 fe35dfd29393b4069d87a06aa729a6608820444b 2989 nvidia-cuda-toolkit_4.2.9-1.dsc
 e6eaf2c7c50105a773639e54e2fd9bc5036c1ed7 485193319 
nvidia-cuda-toolkit_4.2.9.orig.tar.gz
 8d93649c1198e0f15fa130c43a844615aff411b9 28066 
nvidia-cuda-toolkit_4.2.9-1.debian.tar.gz
 9c09beb9051e8d76a5984aeac56d49a4a86a96e5 22151280 
nvidia-cuda-toolkit_4.2.9-1_amd64.deb
 873c0312b6215e073222a13a5667b40e1f2742bd 2178826 
nvidia-cuda-gdb_4.2.9-1_amd64.deb
 c528ef83ac2c521a4d9be82cc03e2b5b835f70e3 41750954 
nvidia-visual-profiler_4.2.9-1_amd64.deb
 af09fd1716d3b453194661402b9eca597797a9ca 520942 
nvidia-cuda-dev_4.2.9-1_amd64.deb
 9b88233dc455f8239091bc273eb91642a9d9c937 12214 
nvidia-opencl-dev_4.2.9-1_amd64.deb
 7a3651f2e67eec9c04a76e83dca97325296147eb 140110 libcudart4_4.2.9-1_amd64.deb
 9b9555c8991e80e2e29d4b6e54d26c3d219363ab 18078922 libcublas4_4.2.9-1_amd64.deb
 6d163cc1c426cb01a1b7fabcecd2754e11f7249b 7316368 libcufft4_4.2.9-1_amd64.deb
 d780e6368b2c08d61ccee1a9a3849aa241e3d75e 25295914 
libcusparse4_4.2.9-1_amd64.deb
 4920665cfe5df6ae9f10bc2b9350ed3e5f02837d 18760488 libcurand4_4.2.9-1_amd64.deb
 ac71ed4ad5a9f8591f524bdbe146cb8eb39c1178 7668222 libnpp4_4.2.9-1_amd64.deb
 6cc9a245507544b31f8d1599b07b3b5d20dfdb48 76184 libcuinj4_4.2.9-1_amd64.deb
 523e9879aa264ea114de00a6d06a62c1b0b53404 89704 libcupti4_4.2.9-1_amd64.deb
 3e18ecdd92fa09bc3ceccd1c9640340c43b9222b 48070 libcupti-dev_4.2.9-1_amd64.deb
 08869b5de017fad11f89c38d0852816397e4a968 28768280 
nvidia-cuda-doc_4.2.9-1_all.deb
 8c010316c217dcaac5047a303b18cb94ec73d2e1 725670 libcupti-doc_4.2.9-1_all.deb
 089dd06e60116d91faf7398efef773a8fd17d3d5 21088832 
nvidia-cuda-toolkit_4.2.9-1_i386.deb
 4b45e59616aeeac62dc0ecd3d6601920c5b8457b 1886456 
nvidia-cuda-gdb_4.2.9-1_i386.deb
 f268b484f39143676e6bda9e0765fde089f98404 41590254 
nvidia-visual-profiler_4.2.9-1_i386.deb
 a911264582a7d13041b3ddbfe709b6b2d7d56f4d 520946 
nvidia-cuda-dev_4.2.9-1_i386.deb
 a636ebd249ce296b2d2e64a53d9cae2e3b2f1d30 12216 
nvidia-opencl-dev_4.2.9-1_i386.deb
 568e42484bb201689adeb0daf4e5144c5b05a4e5 122512 libcudart4_4.2.9-1_i386.deb
 9e997799ab69d864645e920c041e25d7afdb90f4 17543922 libcublas4_4.2.9-1_i386.deb
 b1a76779790453c63f78fbbcfb34aacc3c03ad5a 6734834 libcufft4_4.2.9-1_i386.deb
 d8b83b871dfaca92257e27deadebc79229b38840 23276234 libcusparse4_4.2.9-1_i386.deb
 f985ca3028f0077d5ca9cc8d052c5725956f2eb6 18767094 libcurand4_4.2.9-1_i386.deb
 83686923067571c90ed578b2583d9a7fd21c6baa 7074148 libnpp4_4.2.9-1_i386.deb
 42c686c4323127b6f034aa0300b42edfe73e014d 73346 libcuinj4_4.2.9-1_i386.deb
 6498395d29fc0883c39539a547e24622e65d53c3 95666 libcupti4_4.2.9-1_i386.deb
 b3bfe122ea7effb455aba12e17ab19df1a1099da 48060 libcupti-dev_4.2.9-1_i386.deb
Checksums-Sha256: 
 adc3f0ea08e797b05b11534061ed67f46b5541c296c5e1c5fb2ec8af2870d39c 2989 
nvidia-cuda-toolkit_4.2.9-1.dsc
 ac9a10b4f2da24797e6f3aab31bdcdc2362dbd33e014a3d7b3615500d0dcb24a 485193319 
nvidia-cuda-toolkit_4.2.9.orig.tar.gz
 7ab88bd29b015b0c333e897f5ae78c51e15fb335f876985e040c6cbff52ddffb 28066 
nvidia-cuda-toolkit_4.2.9-1.debian.tar.gz
 291cfcde8c419b1aa18ab12b8d75238f6ed8d47afb8ee817c49c579819d08d14 22151280 

Accepted smarty-validate 3.0.3-2 (source all)

2012-05-11 Thread Mike Gabriel
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 10 May 2012 21:01:53 +0200
Source: smarty-validate
Binary: smarty-validate
Architecture: source all
Version: 3.0.3-2
Distribution: unstable
Urgency: low
Maintainer: Mike Gabriel mike.gabr...@das-netzwerkteam.de
Changed-By: Mike Gabriel mike.gabr...@das-netzwerkteam.de
Description: 
 smarty-validate - Server-side form validation plugin for Smarty
Changes: 
 smarty-validate (3.0.3-2) unstable; urgency=low
 .
   * New maintainer.
Checksums-Sha1: 
 ea5d9ec7def73eee6db717a3f30c3a80f05f31c1 1966 smarty-validate_3.0.3-2.dsc
 ab666e20fee8ff34fa9a7be7d92f27fca6dfb8c6 1547 
smarty-validate_3.0.3-2.debian.tar.gz
 621389cab8bcfccbcfb38ef2560bee4d20e9ba1a 23418 smarty-validate_3.0.3-2_all.deb
Checksums-Sha256: 
 6d893e0faafc27e60bff8985881e433795bca73d670ca48a77e98704ca223db3 1966 
smarty-validate_3.0.3-2.dsc
 b34e5bb8122e7e128805b00bf018bb175332cf81477b75b5c4700574d055703e 1547 
smarty-validate_3.0.3-2.debian.tar.gz
 87d9da8ef276590aafc8fd6cf2f8d214064e8a33fe5b8fd28fe03d2e307f8a6b 23418 
smarty-validate_3.0.3-2_all.deb
Files: 
 2d8d8e0ef25fb86be621343b1b96d2ec 1966 web optional smarty-validate_3.0.3-2.dsc
 2e0e5e79fbe97c08a5786c3a45347970 1547 web optional 
smarty-validate_3.0.3-2.debian.tar.gz
 1e95ef7a709ab72c4dc835ff98f88aea 23418 web optional 
smarty-validate_3.0.3-2_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Signed by Raphael Hertzog

iQIcBAEBCAAGBQJPrMNjAAoJEOYZBF3yrHKaKVMP/R6JG2UMy/pyydSvmTx0Kaaj
Q53HfVXqw7BeHtKNbCqfNCwhJJ2AmHS3MZ8lxnAsB7ZiCnvwfK5dm8QA1PrN67Nb
jwaMaYkcFCGvVs/icy6p1Tyron3oQJdzcqxox7CdAyWTtGiMKOHZOEWbTTIYEPlN
JtBXfuh6kilL/kF/QkrYOewdGe4MdZcT6drjbp55fPczWfvK/QXQ+2XnMFIbRcEw
Xnuj5BnPcUYTfh9dN4Mz0q0RR95k71Hgn7b6P0xLZ8ArG6Ip/5hTHMu+E7Uxylyg
+Jap8eT8vycZgrnOeb7gZTnMckWy+X3JYzmCNJiedHDQP2en8TaRbMzKEYESpIPD
sJLL5GoDTMRRTjgCk86fK11qT8+WnAXeMFATCrS2qn1HG3vq1wh6BPczqpZxjpd+
IJNMUm20qdn0g7tntlujARf4H7p3X2SzVpl1geCQ+k/dFmVBaPQiX8YxMrW/bNK4
5sOAFzCIX+LpkEw5P2p8ltOxynna4obWuqBIwO+jLZHFV/JSA9FyU+bNK+wwPC67
2pcRChb6u1RXT2IHdeFbw8Luq1IM8omMxPL+S/e9YoG7QqlYClAiPQDHwlzz537T
PIFVYc5iw4YhH9LgTzDlYboSfIISlv7PnogqL4KKZZbIU6IqRaLYoNvvWX6hqm7L
Ske20mCoE5HH87VkaFEk
=Mu5g
-END PGP SIGNATURE-


Accepted:
smarty-validate_3.0.3-2.debian.tar.gz
  to main/s/smarty-validate/smarty-validate_3.0.3-2.debian.tar.gz
smarty-validate_3.0.3-2.dsc
  to main/s/smarty-validate/smarty-validate_3.0.3-2.dsc
smarty-validate_3.0.3-2_all.deb
  to main/s/smarty-validate/smarty-validate_3.0.3-2_all.deb


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ssm5j-0004f4...@franck.debian.org



  1   2   >