Re: RFC: OpenRC as Init System for Debian

[Andreas Metzler]

Uoti Urpala  wrote:
> George Danchev wrote:
[...]
>> For some reason or another the vast majority of applications have
>> not been following this approach. I'm not going to argue whether is
>> makes sense or not.

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

Having settings in one (optional) file overide settings in another
one is far from being a new/fresh idea though. See pine.

cu andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/npi189-n4l@argenau.downhill.at.eu.org

Bug#672581: ITP: feincms-elephantblog -- simplistic blog engine for FeinCMS

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: feincms-elephantblog
  Version : 0.1.0
  Upstream Author : Simon Baechler 
* URL : https://github.com/feincms/feincms-elephantblog/
* License : BSD
  Programming Lang: Python
  Description : simplistic blog engine for FeinCMS

Following the principles of FeinCMS, ElephantBlog tries to offer simple and 
basic blog functionality, but remains extensible. Basically, ElephantBlog just 
uses what FeinCMS already has in a blog way. 
..
A blog way means multiple entries in a timeline. One blogentry is similar to 
a FeinCMS page, it can have multiple content types and some meta information 
like title, slug or publishing date.
..
ElephantBlog can also be integrated as application content in an existing 
FeinCMS site, but it does not require the FeinCMS page module to be activated.
..
Features:
 * Pretty URLs
 * Feed creation
 * Time-based publishing
 * Based on FeinCMS item editor with the ability to integrate all of those 
   FeinCMS content types
 * Disqus comments
 * Pinging
 * Categories
 * Multilingual support
 * Pingback & Trackback support


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

iEYEARECAAYFAk+uJpAACgkQeJ3z1zFMUGbPHQCcCRphdbISNwKCgm3VXPU1RplY
WB0An06IacHklN/U1kwXN/3gvLoq57NG
=H3PC
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120512090002.25796.17358.report...@root.fladi.at

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 01:34 AM, Jean-Christophe Dubacq wrote:
> 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.
>   
Yes, I truly agree with the above. We need something to handle changes
better than what we have currently.

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

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> 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.
>   
I like the idea of using Git. Because a new configuration file
with new values would simply get merged with Git, who is quite
smart about doing such merges. Only in complicated merge
conflicts, we'd have to manually solve the issue. For such merge
problems, it'd be great to simply pop a text editor so the user
can decide how to solve the merge conflict.

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

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:19 AM, Gergely Nagy wrote:
> It's perfectly able to notice changes
> in /lib/systemd too, or pretty much anywhere else.
>   
I thought these were only default which we shouldn't
have to care about?!? :)

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

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 03:29 AM, Gergely Nagy wrote:
> It's not etc-overrides-lib that is the problem. It's defaults changing
> without notice that is.

Then, let me ask this:
Do you expect that systemd's default in /lib will change often?

By the way, I finally found the time to try systemd, and I was
shocked to see how fast it booted! :)
The only thing is that I had no clue what started: nothing were
prompted on my screen. Is there a way to have it more verbose?

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

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> 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.
>   
The thing is, if you put the default in a file, it's because you
expect these to change, at least more often than things that
are compiled-in. Otherwise, what's the point in having stuff
stored in a file that can be edited? Why not just do a .h with
the values you need?

Thomas

P.S: I'm continuing to ask, even though you guys are slowly
succeeding in convincing me... :) Not fully though... which
is why I'm continuing this (I believe interesting) discussion.


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

on the use of chmod/chown in maintainer scripts

[Peter Palfrader]

Hey all,

A lot of daemon packages in Debian nowadays create their own user and groups
during installation.  Usually this also implies that a couple of files and
directories are created, and then chmodded and chowned to some appropriate
value for the service in question.

In some cases[1], this chmodding and chowning is done on each package upgrade,
either because things changed over time and just doing it unconditionally seems
like the easiest thing, or just because hey, it doesn't hurt, does it?

Unfortunately, this can be a problem.  Consider a tree /var/lib/example/ that
is owned or writeable by exuid.  If, on upgrades, the package runs chown or
chmod -R /var/lib/example/, or does a chown or chmod on a specific node in that
tree, this implies the possibility of privilige escalation.

A process with uid exuid can just put a hardlink or symlink to
/var/lib/example/ and wait for the next package upgrade.  Voila, they control
/etc/shadow.

| unbound@defiant:~$ pwd
| /var/lib/unbound
| unbound@defiant:~$ id
| uid=112(unbound) gid=120(unbound) groups=120(unbound)
| unbound@defiant:~$ rm root.key
| unbound@defiant:~$ ln -s /etc/shadow root.key
| unbound@defiant:~$ ls -l /etc/shadow
| -rw-r- 1 root shadow 1272 May 12 11:37 /etc/shadow

[wait for the package to be upgraded]

| unbound@defiant:~$ ls -l /etc/shadow
| -rw-r- 1 unbound unbound 1272 May 12 11:37 /etc/shadow

There are some limitations: for instance using symlinks instead of hardlinks
does not usually work when you have to rely on the ch{own,mod} being recursive
- it does work when there is an explicity change for a specific file, e.g.
/var/log/icinga/archives.  Also, recent debian linux kernels carry a patch that
by default limits who can hardlink what[2].  But this will not protect users of
other kernels or people who run earlier linux versions or have that flag
disabled.

This may not be entirely trivial to solve.  find | xargs constructs at best
mitigate this to a race.  While chown does have a --no-derefence flag, this
does not protect us in the case of hardlinks.  chmod has no such flag, and it'd
useful only for symlinks anyway.  Neither tool has a --only-if-link-count-is-one
flag.

What might be needed for the general case is some means that allows packages to
securely upgrade the modes of a tree owned by them, maybe involving
fstat/fchown/fchmod and open with no-follow, also maybe in a declarative way.
Once we had that we could outlaw the use of naive chown and chmod in maintainer
scripts.

Any ideas what we should do?

Aloha,
weasel

1: I didn't do any count of the affected packages, but I come accross these
   issues so often and in packages so prominent, that I feel this survey could
   be delayed until we come to an agreement on whether this is an actually
   issue.  Examples include our exim package, ntp, stunnel4, incinga, and more.

2: fs.protected_hardlinks, see
   https://lists.debian.org/20120302051158.gu12...@decadent.org.uk
-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120512102349.gd19...@anguilla.noreply.org

Re: on the use of chmod/chown in maintainer scripts

[Charles Plessy]

Le Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader a écrit :
> 
> In some cases[1], this chmodding and chowning is done on each package upgrade,
> either because things changed over time and just doing it unconditionally 
> seems
> like the easiest thing, or just because hey, it doesn't hurt, does it?
> 
> Unfortunately, this can be a problem.  Consider a tree /var/lib/example/ that
> is owned or writeable by exuid.  If, on upgrades, the package runs chown or
> chmod -R /var/lib/example/, or does a chown or chmod on a specific node in 
> that
> tree, this implies the possibility of privilige escalation.

Hi all,

I was always wondering:

Unless we expect that two different binary packages that can be co-installed
will distribute the same directory under different ownership or permissions for
a good reason, why not simply let dpkg apply ownership and permissions found in
data.tar.{gz|bz2|xz}, and treat it the same as a file conflict when unpacking a
package on a system where another package has already set different ownersip
and permissions ?

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/20120512111010.gc31...@falafel.plessy.net

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/12/2012 03:29 AM, Gergely Nagy wrote:
>> It's not etc-overrides-lib that is the problem. It's defaults changing
>> without notice that is.
>
> Then, let me ask this:
> Do you expect that systemd's default in /lib will change often?

Nope.

> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

If you remove 'quiet' from the kernel command line, yes.

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

Re: RFC: OpenRC as Init System for Debian

[Gergely Nagy]

Thomas Goirand  writes:

> On 05/12/2012 03:19 AM, Gergely Nagy wrote:
>> It's perfectly able to notice changes
>> in /lib/systemd too, or pretty much anywhere else.
>>   
> I thought these were only default which we shouldn't
> have to care about?!? :)

You don't change defaults, but if you get notified when they do change,
that's nice. I personally don't care, because there's only two things I
override (syslog.service and media.mount), and I couldn't care less of
the default in either case. :P

But since there were a lot of "but if it changes I get no
notification!!!1!" shoutings going on in here, I figured I'll mention
that this solution is suitable for that notification purpose as well.

It will notify you of all two cases that'll happen in the next year or
two! >:)

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

Re: RFC: OpenRC as Init System for Debian

[Jon Dowland]

On Sat, May 12, 2012 at 05:21:03PM +0800, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

This is probably better directed at a user-oriented list, or a systemd
specific list. (Although I have seen the answer posted in this thread
at least once.)


-- 
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/20120512110535.GB30842@debian

Re: RFC: OpenRC as Init System for Debian

[Michael Biebl]

On 12.05.2012 11:21, Thomas Goirand wrote:
> By the way, I finally found the time to try systemd, and I was
> shocked to see how fast it booted! :)
> The only thing is that I had no clue what started: nothing were
> prompted on my screen. Is there a way to have it more verbose?

1/ Remove "quiet" from the kernel command line. This also has influence
on the verbosity of the kernel itself. If you don't like the kernel message:
2/ Add "systemd.sysv_console=true systemd.show_status=true" to the
kernel command line.

man 1 systemd → "KERNEL COMMAND LINE"

-- 
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: on the use of chmod/chown in maintainer scripts

[Roger Leigh]

On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> A lot of daemon packages in Debian nowadays create their own user and groups
> during installation.  Usually this also implies that a couple of files and
> directories are created, and then chmodded and chowned to some appropriate
> value for the service in question.
> 
> Any ideas what we should do?

Like for other parts of the packaging and maintainer scripts, I think
this is something which should be entirely declarative, and handled
at the dpkg or debhelper level.

In the case of adding users and groups, it would be helpful to have
e.g. a dh_user and/or dh_group script which look at
debian/${package}.(user|group) and put the appropriate
adduser/useradd commands into the package preinst or postinst, and
depends/pre-depends on the needed tools as appropriate.
This can also add the appropriate commands for removal in the postrm
(or not, as the consensus currently appears to be).  But the policy
for that can be set by debhelper.

Why the preinst?  If all static or dynamic users and groups are made
available before unpacking the data.tar, we can just unpack the tar
and the users/groups in the files and directories could be
automatically used.  No manual chmod/chown would be required, since
this would all be handled transparently by dpkg.

With the above approach, the only hard question is how to set the
ownership during the package build.  fakeroot handles this just fine,
but it does require the user/group to be present on the build
system, which will not always be the case.  Is there an alternative
means to set/override the ownership during packing of a tarfile?


Regards,
Roger

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


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

Re: on the use of chmod/chown in maintainer scripts

[Sven Joachim]

On 2012-05-12 13:10 +0200, Charles Plessy wrote:

> I was always wondering:
>
> Unless we expect that two different binary packages that can be co-installed
> will distribute the same directory under different ownership or permissions 
> for
> a good reason, why not simply let dpkg apply ownership and permissions found 
> in
> data.tar.{gz|bz2|xz}, and treat it the same as a file conflict when unpacking 
> a
> package on a system where another package has already set different ownersip
> and permissions ?

An obvious obstacle is that dpkg does not currently track ownership and
permissions of installed files and directories in its database.

Cheers,
   Sven


-- 
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/87zk9dpqr1@turtle.gmx.de

Re: RFC: OpenRC as Init System for Debian

[Roger Leigh]

On Sat, May 12, 2012 at 05:25:57PM +0800, Thomas Goirand wrote:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
> > 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.
> >   
> The thing is, if you put the default in a file, it's because you
> expect these to change, at least more often than things that
> are compiled-in. Otherwise, what's the point in having stuff
> stored in a file that can be edited? Why not just do a .h with
> the values you need?
> 
> P.S: I'm continuing to ask, even though you guys are slowly
> succeeding in convincing me... :) Not fully though... which
> is why I'm continuing this (I believe interesting) discussion.

At this point, I think all the pros and cons of all the various
different strategies have been discussed ad nauseam--there's not
much of value in continuing this further on this list.  It's not
adding anything new or useful.


Regards,
Roger

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


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

Re: Directory /boot/console-setup

[Anton Zinoviev]

On Fri, May 11, 2012 at 09:07:57AM +0200, Tollef Fog Heen wrote:
> ]] 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

Ok, then it will be /etc/console-setup/cache (no dot).

On Thu, May 10, 2012 at 02:54:16PM -0700, Steve Langasek wrote:
> On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote:
> > Currently it creates files in the directory /etc/console-setup.  As 
> > a result when the package is purged it is impossible to tell which 
> > files in /etc/console-setup are automatically generated (so they 
> > have to be removed) and which are put there by the admin (so we are 
> > not permitted to remove them).
> 
> I think your premise here is false.  The /etc/console-setup directory is
> owned by the console-setup package; there are certain predictable filenames

The file names are not predictable unless one has acces to all previous 
versions of the configuration files.  But even if they were predictable 
we would need MD5 or other hash to be sure the files have not be 
modified somehow by the admin.

Yves-Alexis Perez wrote on debian-devel:
> 
> What do you mean with “this doesn't work in Debian”? Some people do use
> encrypted root and they do have a working console asking for the
> passphrase.

As far as I know currently the console works with default settings, 
meaning the keyboard is standard US-QWERTY layout.

Anton Zinoviev



-- 
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/20120512120431.ga22...@logic.fmi.uni-sofia.bg

Re: on the use of chmod/chown in maintainer scripts

[Guillem Jover]

On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote:
> On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> > A lot of daemon packages in Debian nowadays create their own user and groups
> > during installation.  Usually this also implies that a couple of files and
> > directories are created, and then chmodded and chowned to some appropriate
> > value for the service in question.
> > 
> > Any ideas what we should do?
> 
> Like for other parts of the packaging and maintainer scripts, I think
> this is something which should be entirely declarative, and handled
> at the dpkg or debhelper level.
> 
> In the case of adding users and groups, it would be helpful to have
> e.g. a dh_user and/or dh_group script which look at
> debian/${package}.(user|group) and put the appropriate
> adduser/useradd commands into the package preinst or postinst, and
> depends/pre-depends on the needed tools as appropriate.
> This can also add the appropriate commands for removal in the postrm
> (or not, as the consensus currently appears to be).  But the policy
> for that can be set by debhelper.
> 
> Why the preinst?  If all static or dynamic users and groups are made
> available before unpacking the data.tar, we can just unpack the tar
> and the users/groups in the files and directories could be
> automatically used.  No manual chmod/chown would be required, since
> this would all be handled transparently by dpkg.

Right, this came up some time ago when Lars blogged about it, my reply
to that can be found there:

  

> With the above approach, the only hard question is how to set the
> ownership during the package build.  fakeroot handles this just fine,
> but it does require the user/group to be present on the build
> system, which will not always be the case.  Is there an alternative
> means to set/override the ownership during packing of a tarfile?

One option would be to make dpkg-deb use an internal tar implementation,
and add a file describing the attributes of the to be packaged files.
That might make needing root privs (either through fakeroot or sudo)
unneeded in most of the cases too.

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/20120512135523.ga...@gaara.hadrons.org

Re: Bug#632240: pylucene status

[Adam D. Barratt]

On 20.04.2012 17:16, Dmitry Nezhevenko wrote:

On Fri, Apr 20, 2012 at 08:50:24AM -0700, Jeff Breidenbach wrote:
You can package a modern pylucene and take over as the maintainer. 
Nothing

would make me happier.


Thanks a lot! I'll try to do this


Any news on that?  I'm looking at old FTBFS issues as part of the York 
BSP and right now pyluence looks like an RM candidate.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/e6d09decc060853b74c9917d2f4e4...@mail.adsl.funky-badger.org

Re: Directory /boot/console-setup

[Steve Langasek]

On Sat, May 12, 2012 at 03:04:31PM +0300, Anton Zinoviev wrote:
> On Thu, May 10, 2012 at 02:54:16PM -0700, Steve Langasek wrote:
> > On Thu, May 10, 2012 at 07:43:46PM +0300, Anton Zinoviev wrote:
> > > Currently it creates files in the directory /etc/console-setup.  As 
> > > a result when the package is purged it is impossible to tell which 
> > > files in /etc/console-setup are automatically generated (so they 
> > > have to be removed) and which are put there by the admin (so we are 
> > > not permitted to remove them).

> > I think your premise here is false.  The /etc/console-setup directory is
> > owned by the console-setup package; there are certain predictable filenames

> The file names are not predictable unless one has acces to all previous 
> versions of the configuration files.  But even if they were predictable 
> we would need MD5 or other hash to be sure the files have not be 
> modified somehow by the admin.

No, you absolutely do *not* need this.  The policy rule isn't "on purge,
remove all config files if the admin hasn't edited them", it's "on purge,
remove *all configuration files*".

This "cache" subdirectory is pointless complexity.  The existing rm -rf
behavior is appropriate.

-- 
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: Bug#632240: pylucene status

[Dmitry Nezhevenko]

On Sat, May 12, 2012 at 03:00:11PM +0100, Adam D. Barratt wrote:
> On 20.04.2012 17:16, Dmitry Nezhevenko wrote:
> >On Fri, Apr 20, 2012 at 08:50:24AM -0700, Jeff Breidenbach wrote:
> >>You can package a modern pylucene and take over as the
> >>maintainer. Nothing
> >>would make me happier.
> >
> >Thanks a lot! I'll try to do this
> 
> Any news on that?  I'm looking at old FTBFS issues as part of the
> York BSP and right now pyluence looks like an RM candidate.

Hi,

I'm very motivated to support this package since it's optional dependency
of ReviewBoard package. I'm not DD so can't upload it. That's why I've
uploaded new version of pylucene to mentors and looking for sponsor:

Bug#670204: RFS: pylucene/3.5.0-1 ITA -- Python extension for accessing Java 
Lucene 

Holger Levsen will probably take a look to it in a week. He is on a
vacation now but proposed sponsorship for reviewboard in it's ITP.

-- 
WBR, Dmitry


signature.asc
Description: Digital signature

ITP: italc2 -- Intelligent Teaching and Learning with Computers

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

  Package name: italc2
  Version : 2.0.0
  Upstream Author : Tobias Doerffel 
  URL : http://italc.sourceforge.net/home.php
  License : GPLv2+
  Programming Lang: C++/Qt
  Description : Intelligent Teaching and Learning with Computers

iTALC2 is a useful and powerful didactical tool for teachers. It lets  
you view and control other computers in your network in several ways.  
It supports Linux and Windows XP, Vista and 7 and it even can be used  
transparently in mixed environments!


iTALC2 has been designed for usage in school. Therefore it offers a  
lot of possibilities to teachers, such as


  * see what's going on in computer-labs by using overview mode and make
  snapshots
  * remote control computers to support and help other people
  * show a demo (either in fullscreen or in a window) - the teacher's  
screen is

  shown on all student's computers in realtime
  * lock workstations for moving undivided attention to teacher
  * send text messages to students
  * powering on/off and rebooting computers per remote
  * remote logon and logoff and remote execution of arbitrary commands/scripts
  * home schooling - iTALC's network-technology is not restricted to a subnet
 and therefore students at home can join lessons via VPN-connections just
 by installing iTALC client

Furthermore iTALC is optimized for usage on multi-core systems (by  
making heavy use of threads). No matter how many cores you have, iTALC  
can make use of all of them.


The italc2 src:package will finally supersede the currently available  
Debian src:package italc.



--

DAS-NETZWERKTEAM
mike gabriel, dorfstr. 27, 24245 barmissen
fon: +49 (4302) 281418, fax: +49 (4302) 281419

GnuPG Key ID 0xB588399B
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb


pgpUWZzvpu0PS.pgp
Description: Digitale PGP-Unterschrift

Re: RFC: OpenRC as Init System for Debian

[Nikolaus Rath]

Thomas Goirand  writes:
> On 05/11/2012 05:07 PM, Gergely Nagy wrote:
>> 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.
>>   
> The thing is, if you put the default in a file, it's because you
> expect these to change, at least more often than things that
> are compiled-in. Otherwise, what's the point in having stuff
> stored in a file that can be edited? Why not just do a .h with
> the values you need?

The advantage of having the defaults in a file is that it makes it much
easier to inspect them. A .h file would typically not be installed, so
it wouldn't be readily available. In addition to that, it is much less
expressive. The nice thing about storing the default values in the same
format used by the configuration file is that if you find a default that
you'd like to change, you immediately know what to put in the
configuration file in order to change it.


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/87k40hh502@vostro.rath.org

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

[Thomas Preud'homme]

Le samedi 12 mai 2012 04:25:08, Russ Allbery a écrit :
> Michael Gilbert  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.

Are you referring to [1]? Because the full paragraph is about Program's source 
code.

[1] http://lists.debian.org/debian-policy/2000/11/msg00260.html

"  1. You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program."

To me Program should be read here as "Program in source code form"

As to point 3 referring to points 1, it says:

"  3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following(…)"

I don't think it means the object code must provide a license, just that the 
program which is redistributed respect points 1 and 2.


Best regards.


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

Wheezy release: CDs are not big enough any more...

[Steve McIntyre]

Hey folks,

Remembering the fun that we had during the Squeeze release with trying
to make single-CD installations work well, it's time to consider what
we're going to *claim* to support in Wheezy. We've had a history of
supporting the following single-CD installations:

 * Gnome desktop from CD#1
 * KDE desktop from "KDE CD#1"
 * XFCE desktop from "light CD#1"
 * LXDE desktop from "light CD#1"
 * base system only from netinst CD

At this point, I'm skeptical that either of the first two are going to
work acceptably with Wheezy. If that's the case, then we should warn
people that they will need to use at least one of:

 * more CDs
 * a DVD
 * a network mirror

to get a useful/useable installation.

Gnome/KDE people: if you *can* do a single-CD installation for Wheezy,
please say so. If not, we'll need to make sure we get documents
updated (like the Release Manual), and maybe even consider extra
release images (e.g. a 2GB USB stick image).

Talk to me, please...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Into the distance, a ribbon of black
Stretched to the point of no turning back


-- 
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/20120512160416.gm24...@einval.com

Re: Strange bug in Qt program after build with gcc 4.7

[Boris Pek]

Hi,

Problem is solved. Thanks a lot to Pino Toscano.

Regards,
Boris


-- 
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/1164201336840...@web15e.yandex.ru

Re: Bug#672160: Directory /boot/console-setup

[Anton Zinoviev]

On Sat, May 12, 2012 at 07:01:20AM -0700, Steve Langasek wrote:
> 
> No, you absolutely do *not* need this.  The policy rule isn't "on purge,
> remove all config files if the admin hasn't edited them", it's "on purge,
> remove *all configuration files*".

All configuration files owned by the package.  There is no way to tell 
whether a file in /etc/console-setup is owned by the package console-setup
or it has been put there by the admin and is unrelated to console-setup.

Anton Zinoviev


-- 
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/20120512170415.ga23...@logic.fmi.uni-sofia.bg

Re: Wheezy release: CDs are not big enough any more...

[Adam Borowski]

On Sat, May 12, 2012 at 05:04:16PM +0100, Steve McIntyre wrote:
> Hey folks,
> 
> Remembering the fun that we had during the Squeeze release with trying
> to make single-CD installations work well, it's time to consider what
> we're going to *claim* to support in Wheezy. We've had a history of
> supporting the following single-CD installations:
> 
>  * Gnome desktop from CD#1
>  * KDE desktop from "KDE CD#1"
> 
> At this point, I'm skeptical that either of the first two are going to
> work acceptably with Wheezy.

There is an easy solution: switch binary packages to xz compression.

amd64's CD 1 is reduced to 2/3 of its current size (data from June(?) 2010).

If you remember, I also did some research for the whole archive:

Thread: https://lists.debian.org/debian-devel/2011/08/msg00220.html
Raw data: http://angband.pl/deb/xz/debs.txt

There is a misconception that only big packages are worth compressing.  Ten
small packages give almost as good savings as one big.  xz is indeed worse
than gzip for smallest packages (~1-2KB) but the total savings that could be
gained by a smart selection of the compression method are so small that
they're not worth any extra complexity.

xz has decompression speed hardly slower than gzip (as opposed to bzip2). 
It has vastly slower compression, though: testing on three packages, on
amd64 it slows package builds by ~5%, on armel by ~2% (it was a _really_
unexhaustive test, though).  And if this is a blocker, you can repack
binaries afterwards, possibly on one of idle cores on that big amd64 machine
standing near your armel/m68k buildd.

Unlike last August when we had that discussion, neither debootstrap nor d-i
have any problems with xz anymore.


Thus, let's just switch dpkg-deb's default to xz.  Lowering bandwidth usage
is worth the extra build time cost.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Bug#672659: ITP: libmkv -- Alternative to the official libmatroska/libebml libraries

[Andres Mejia]

Package: wnpp
Severity: wishlist
Owner: Debian Multimedia Maintainers 


* Package name: libmkv
  Version : 0.6.5.1
  Upstream Author : saint...@gmail.com
* URL : https://github.com/saintdev/libmkv
* License : GPLv2+
  Programming Lang: C
  Description : Alternative to the official libmatroska/libebml libraries

This library is meant to be an alternative to the official libmatroska
library.  It is writen (Thanks Haali) in plain C, and intended to be very
portable.



-- 
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/4faea0de.09b4e00a.7d9b.1...@mx.google.com

Re: Wheezy release: CDs are not big enough any more...

[Philipp Kern]

On Sat, May 12, 2012 at 07:33:49PM +0200, Adam Borowski wrote:
> Unlike last August when we had that discussion, neither debootstrap nor d-i
> have any problems with xz anymore.

For udebs it will come after alpha 1.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Wheezy release: CDs are not big enough any more...

[Adam Borowski]

On Sat, May 12, 2012 at 08:07:13PM +0200, Philipp Kern wrote:
> On Sat, May 12, 2012 at 07:33:49PM +0200, Adam Borowski wrote:
> > Unlike last August when we had that discussion, neither debootstrap nor d-i
> > have any problems with xz anymore.
> 
> For udebs it will come after alpha 1.

Regular debs are unpacked far from any memory-critical paths (it's unpack,
configure, unpack, configure), but I don't know enough about d-i to risk
increasing the minimal memory requirement, which would be likely to happen
if udebs switched to xz (unpacking takes ~10MB memory).

So I didn't even look at any potential gains for udebs themselves, sorry for
forgetting to mention that.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


signature.asc
Description: Digital signature

Re: RFC: OpenRC as Init System for Debian

[Thomas Goirand]

On 05/12/2012 10:02 PM, Nikolaus Rath wrote:
> The advantage of having the defaults in a file is that it makes it much
> easier to inspect them. A .h file would typically not be installed, so
> it wouldn't be readily available. In addition to that, it is much less
> expressive. The nice thing about storing the default values in the same
> format used by the configuration file is that if you find a default that
> you'd like to change, you immediately know what to put in the
> configuration file in order to change it.
>   
Then why not simply write this in /usr/share/doc//examples ?

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

Re: RFC: OpenRC as Init System for Debian

[Vincent Bernat]

OoO  Pendant le  journal télévisé  du samedi  12 mai  2012,  vers 20:58,
Thomas Goirand  disait :

>> The advantage of having the defaults in a file is that it makes it much
>> easier to inspect them. A .h file would typically not be installed, so
>> it wouldn't be readily available. In addition to that, it is much less
>> expressive. The nice thing about storing the default values in the same
>> format used by the configuration file is that if you find a default that
>> you'd like to change, you immediately know what to put in the
>> configuration file in order to change it.
>> 
> Then why not simply write this in /usr/share/doc//examples ?

Because they  are the  defaults of the  application, not  examples. This
conversation is going nowhere.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

 /* Thanks to Rob `CmdrTaco' Malda for not influencing this code in any
  * way.
  */
2.4.3 linux/net/core/netfilter.c


pgppM9vVpexlQ.pgp
Description: PGP signature

Re: Bug#672160: Directory /boot/console-setup

[Steve Langasek]

On Sat, May 12, 2012 at 08:04:15PM +0300, Anton Zinoviev wrote:
> On Sat, May 12, 2012 at 07:01:20AM -0700, Steve Langasek wrote:

> > No, you absolutely do *not* need this.  The policy rule isn't "on purge,
> > remove all config files if the admin hasn't edited them", it's "on purge,
> > remove *all configuration files*".

> All configuration files owned by the package.

This is not an interesting distinction.

> There is no way to tell whether a file in /etc/console-setup is owned by
> the package console-setup or it has been put there by the admin and is
> unrelated to console-setup.

Who cares?  If the admin is putting files in a directory named
"/etc/console-setup" that are *unrelated to console-setup*, there's no
reason to coddle them by making the console-setup's maintainer scripts more
complex.

And most package maintainers have not bothered to implement such handling. 
So an admin who hasn't yet learned the lesson to not put random files in
unrelated directories under /etc will have plenty of opportunities to learn
it before purging such a basic package as console-setup.

-- 
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: Wheezy release: CDs are not big enough any more...

[Timo Juhani Lindfors]

Steve McIntyre  writes:
> At this point, I'm skeptical that either of the first two are going to
> work acceptably with Wheezy. If that's the case, then we should warn
> people that they will need to use at least one of:

I agree. I tried installing debian gnome desktop from CD1 during last
debconf and ended up getting a system that does not have network manager
or support for suspend:

http://lists.debian.org/debian-boot/2011/08/msg00172.html

Since Debian is universal I can understand that we can't fit the desktop
to CD1 but I think we should clearly state that so that users are not
surprised by the crippled system they get after the installation is
finished.


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

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

[Russ Allbery]

"Thomas Preud'homme"  writes:

> Are you referring to [1]? Because the full paragraph is about Program's
> source code.

> [1] http://lists.debian.org/debian-policy/2000/11/msg00260.html

> " 1. You may copy and distribute verbatim copies of the Program's source
> code as you receive it, in any medium, provided that you conspicuously
> and appropriately publish on each copy an appropriate copyright notice
> and disclaimer of warranty; keep intact all the notices that refer to
> this License and to the absence of any warranty; and give any other
> recipients of the Program a copy of this License along with the
> Program."

> To me Program should be read here as "Program in source code form"

Program is explicitly defined in the GPL and that's not what the
definition is.

This License applies to any program or other work which contains a
notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.  The "Program", below,
refers to any such program or work, and a "work based on the Program"
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language.

So Program is anything with a notice saying that the GPL applies to it.
And since you're required to preserve such a notice in derivative works as
another one of the requirements in point 1 (which is incorporated into
point 3), all derivative works will have such a notice.

It's not phrased very clearly, certainly.  The GPL 3 fixes this.  But you
have to split a lot of hairs to convince yourself that Program refers only
to source code distributions.  (Which didn't stop people in that
discussion from splitting those hairs, but I didn't find it convincing.)

> As to point 3 referring to points 1, it says:

> " 3. You may copy and distribute the Program (or a work based on it,
> under Section 2) in object code or executable form under the terms of
> Sections 1 and 2 above provided that you also do one of the
> following(…)"

> I don't think it means the object code must provide a license, just that
> the program which is redistributed respect points 1 and 2.

Point 3 says that, when distributing the Program, you have to comply with
all of the requirements of point 1.  Point 1 says "...and give any other
recipients of the Program a copy of this License along with the Program."

In order to believe that this requirement does not apply, you have to
believe that, because point 1 says "the Program's source code" at the
start, that means that it doesn't apply to distributions of the Program
that are not source code, despite the fact that point 3 explicitly says
that the requirements of point 1 apply.  I don't think that's a reasonable
interpretation, since by that reading the statement in point 3 that you
have to follow point 1 is meaningless (it doesn't add any additional
requirements).  There's a standard rule in US contract law that says that
you must always favor the interpretation of a contract that does not make
parts of the contract meaningless.

The GPL 3 fixes this ambiguity too, btw, by making it explicit that you
have to distribute a copy of the license with binary works, which is more
evidence of what the intent is.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87fwb5rud4@windlord.stanford.edu

Re: on the use of chmod/chown in maintainer scripts

[Russ Allbery]

Charles Plessy  writes:

> Unless we expect that two different binary packages that can be
> co-installed will distribute the same directory under different
> ownership or permissions for a good reason, why not simply let dpkg
> apply ownership and permissions found in data.tar.{gz|bz2|xz},

Usually because the UID is dynamically assigned and the user is created in
the postinst, so there's no way for dpkg do do this at unpack.

You would need to apply permissions by name, not UID/GID, and you would
need to create all users in preinst prior to unpack, which would require
Pre-Depends on adduser with all the complexity that entails.  I haven't
thought through that path to see if there are any other problems.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878vgxrtx3@windlord.stanford.edu

Re: Wheezy release: CDs are not big enough any more...

[Marco d'Itri]

On May 12, Adam Borowski  wrote:

> Thus, let's just switch dpkg-deb's default to xz.  Lowering bandwidth usage
> is worth the extra build time cost.
Agreed, this looks like a good idea.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: on the use of chmod/chown in maintainer scripts

[Roger Leigh]

On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> On Sat, 2012-05-12 at 12:28:27 +0100, Roger Leigh wrote:
> > On Sat, May 12, 2012 at 12:23:49PM +0200, Peter Palfrader wrote:
> > With the above approach, the only hard question is how to set the
> > ownership during the package build.  fakeroot handles this just fine,
> > but it does require the user/group to be present on the build
> > system, which will not always be the case.  Is there an alternative
> > means to set/override the ownership during packing of a tarfile?
> 
> One option would be to make dpkg-deb use an internal tar implementation,
> and add a file describing the attributes of the to be packaged files.
> That might make needing root privs (either through fakeroot or sudo)
> unneeded in most of the cases too.

I found that this functionality is already present in BSD tar,
according to the manpage.  You can provide a file containing
all the files to pack, plus their ownership and perms etc.,
rather than just specifying the files on the command-line.

bsdtar(1)
An input file in mtree(5) format can be used to create an output archive
with arbitrary ownership, permissions, or names that differ from existing
data on disk:

 $ cat input.mtree
 #mtree
 usr/bin uid=0 gid=0 mode=0755 type=dir
 usr/bin/ls uid=0 gid=0 mode=0755 type=file content=myls
 $ tar -cvf output.tar @input.mtree
-

I can't see an equivalent in GNU tar.  But BSD tar is available
in Debian.


Regards,
Roger

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


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

Bug#672695: wordpress: no sane way for security updates in stable releases

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wordpress
Severity: grave
Version: 3.3.2+dfsg-1

[CC-in d-devel@l.d.o to discuss this]

Hi,

although I think the wordpress maintainer are doing all they can do to keep
wordpress in a good shape in Debian, I do not think that it is possible to
support a stable version with security fixes as we expect it for our releases.
The last security update shows that the wordpress upstream is not interested
in helping by documenting their patches or shipping proper point-releases to
at least some versions.

Being forced to upgrade to a new major version by a stable security support is
nothing we should force our users to. Debian stable is known for (usually)
painfree updates and bugfixes only, not for shipping completely new versions
with a forced migration. Therefore - in my opinion - we should not ship
wordpress in Wheezy, at least not until upstream handles such issues in a sane
way.


Cheers,

Bernd



-  Original Message 
Subject: [SECURITY] [DSA 2670-1] wordpress security update
Resent-Date: Fri, 11 May 2012 20:41:44 + (UTC)
Resent-From: debian-security-annou...@lists.debian.org
Date: Fri, 11 May 2012 22:41:14 +0200
From: Yves-Alexis Perez 
Reply-To: debian-secur...@lists.debian.org
To: debian-security-annou...@lists.debian.org

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- - -
Debian Security Advisory DSA-2670-1   secur...@debian.org
http://www.debian.org/security/ Yves-Alexis Perez
May 11, 2012   http://www.debian.org/security/faq
- - -

Package: wordpress
Vulnerability  : several
Problem type   : remote
Debian-specific: no
CVE ID : CVE-2011-3122 CVE-2011-3125 CVE-2011-3126 CVE-2011-3127
 CVE-2011-3128 CVE-2011-3129 CVE-2011-3130 CVE-2011-4956
 CVE-2011-4957 CVE-2012-2399 CVE-2012-2400 CVE-2012-2401
 CVE-2012-2402 CVE-2012-2403 CVE-2012-2404
Debian Bug : 670124

Several vulnerabilities were identified in Wordpress, a web blogging
tool.  As the CVEs were allocated from releases announcements and
specific fixes are usually not identified, it has been decided to
upgrade the Wordpress package to the latest upstream version instead
of backporting the patches.

This means extra care should be taken when upgrading, especially when
using third-party plugins or themes, since compatibility may have been
impacted along the way.  We recommend that users check their install
before doing the upgrade.

For the stable distribution (squeeze), those problems have been fixed in
version 3.3.2+dfsg-1~squeeze1.

For the testing distribution (wheezy) and the unstable distribution
(sid), those problems have been fixed in version 3.3.2+dfsg-1.

We recommend that you upgrade your wordpress packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: http://www.debian.org/security/

Mailing list: debian-security-annou...@lists.debian.org
- -BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJPrXyJAAoJEL97/wQC1SS+4EcH/1nAhgTx17pMJF7JbWFNG2ZY
/xSD6v4MDj3pLiZrntRx4c3y+Kbx91QKBN6KgqDxyHjDLoZgoNVVGwyozGjS2VBn
m2OwnjzLUJVqd77R+mUj5h3yEVS1d4O+VcYRcpugPTaD17d90rlPGL2HkZXnQAk1
OjOKGns+yiapuLpcHmNz5cjwvJxaNe355aZlwSUjFWumqtGjQcgyJeKy1XGW0s2o
h9YnLXGRNwtihXz0P+5qx7Qwcri3PXLn1Uapp2RSJStkNfiRjSJoqUkb5wqvhT7x
O6GhUWShBF6pZ11uvOySY2yU5jPOQDufSUn6T4R5CL4hYJ6Bif6iqkHznPubHeE=
=M38G
- -END PGP SIGNATURE-


- -- 
To UNSUBSCRIBE, email to debian-security-announce-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ipg2e9hx@mid.deneb.enyo.de

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJPrtniAAoJEOs2Fxpv+UNf1TMP/RsGS4DGRSe0i6F2dt/QVnvF
Vcbe9UPTnNxfQlN62hDuhvck+v3c4wNwoXW5iblJ9FCJXjCM9Lvl/6aRXnE4E0QH
1TUf2vzDNmI6IUVtD+bdbVopBuqhOpmJOG+96HQua/aPIIhgjw6C4SzcFU+WyE6R
AC2Vm98/spmr73fBn/bXH0NPlcOERoJl8rwORsM+fnevRgnknbWasmwHNeKXJwKT
dN6HnWtEHjRqEqus2JUOJpqL0bYvWLo22WSdZIETuPWVHslMtgDsfWEuEN4bJtq8
aYqYBJ3SCYK4phSYfBpdukFkmOkVhB5mG+PqwG+32Ib9TEufH+guxmMj0Gpt3lMj
KddKDSIFrwUUKESVy0NYRIJLiGPpHW1Tb/dc7HJry7+ls+2+iAvQjDMFuJ1MtO2t
zemN7uKAqL72JBLkvC44i8PXuKvvGaaroC2HGTKpxz9JesZlw/yDzvama268w4bY
RBkCeewPklMsKesJXzWM6NzcFnFr4s1PKO+dGHkCut83tlRY2u8O95agGNeFkxIt
+skWpaAoV5BM7XFcyzzY2s6u6/nDGMaANHJDimci0YCT0fQbZms3KhXYU5eow/tv
U7/ynZvEMrRkaNlKoBSzn1rAgeP9bFsCAtob7xfP2rtB862Va1MzsdXfWfdS+w8a
FLRn9NVg5kWeH01K9kQJ
=UM+T
-END PGP SIGNATURE-



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

Re: Wheezy release: CDs are not big enough any more...

[Charles Plessy]

Le Sat, May 12, 2012 at 07:33:49PM +0200, Adam Borowski a écrit :
> 
> There is an easy solution: switch binary packages to xz compression.
> 
> amd64's CD 1 is reduced to 2/3 of its current size (data from June(?) 2010).
> 
> If you remember, I also did some research for the whole archive:
> 
> Thread: https://lists.debian.org/debian-devel/2011/08/msg00220.html
> Raw data: http://angband.pl/deb/xz/debs.txt
> 
> There is a misconception that only big packages are worth compressing.  Ten
> small packages give almost as good savings as one big.  xz is indeed worse
> than gzip for smallest packages (~1-2KB) but the total savings that could be
> gained by a smart selection of the compression method are so small that
> they're not worth any extra complexity.

In my experience, xz gives the biggest gains, like halving the size of a
package, when its contents are rich in binary files.  So if heuristics are
needed, perhaps that could be a direction...

Another gain from xz compression is mirror space.  Consider the gain doubled
when the same provider also has a Ubuntu mirror !  Disk space may be cheap, but
they require energy to operate, and that is becoming something more and more
precious in our world.

Have a nice Sunday,

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


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

Re: Directory /boot/console-setup

[intrigeri]

Hi,

Anton Zinoviev wrote (12 May 2012 12:04:31 GMT) :
> Yves-Alexis Perez wrote on debian-devel:
>> 
>> What do you mean with “this doesn't work in Debian”? Some people do use
>> encrypted root and they do have a working console asking for the
>> passphrase.

> As far as I know currently the console works with default settings,
> meaning the keyboard is standard US-QWERTY layout.

Well, while this is currently true as far as testing/sid is concerned,
but this is actually a regression:

On Squeeze, one may happily use a non-US layout in the initramfs to
enter their encrypted root passphrase.

On Wheezy, this is currently broken, at least for fresh installs
(#619711).


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

Re: Wheezy release: CDs are not big enough any more...

[Guillem Jover]

On Sat, 2012-05-12 at 17:04:16 +0100, Steve McIntyre wrote:
> Remembering the fun that we had during the Squeeze release with trying
> to make single-CD installations work well, it's time to consider what
> we're going to *claim* to support in Wheezy. We've had a history of
> supporting the following single-CD installations:

Yes, I'd not see any problem from my side with switching the default
dpkg-deb compression to xz for 1.16.4, if people are fine with that (as
long as it's not conditional). Last time there were some concerns about
slow architectures or low memory systems, but the default preset is
quite conservative so I don't really see the issue. And if specific
packages are problematic they can always decide to use another
compression type or level. Also if udeb:s are going to be using
xz then it makes even more sense to use it for everything.

thanks,
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/20120513000625.ga6...@gaara.hadrons.org

Re: on the use of chmod/chown in maintainer scripts

[Guillem Jover]

On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> > One option would be to make dpkg-deb use an internal tar implementation,
> > and add a file describing the attributes of the to be packaged files.
> > That might make needing root privs (either through fakeroot or sudo)
> > unneeded in most of the cases too.
> 
> I found that this functionality is already present in BSD tar,
> according to the manpage.  You can provide a file containing
> all the files to pack, plus their ownership and perms etc.,
> rather than just specifying the files on the command-line.
> 
> bsdtar(1)
> An input file in mtree(5) format can be used to create an output archive
> with arbitrary ownership, permissions, or names that differ from existing
> data on disk:
[...]
> -

Yeah, mtree is actually one of the things I've been having in mind
when considering ways to store file metadata in the dpkg suite.

> I can't see an equivalent in GNU tar.  But BSD tar is available
> in Debian.

This would imply BSD tar needs to be promoted to the Essential set
alongside GNU tar, at which point I might as well just use an
internal tar implementation.

thanks,
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/20120513001013.gb6...@gaara.hadrons.org

Re: on the use of chmod/chown in maintainer scripts

[Roger Leigh]

On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote:
> On Sat, 2012-05-12 at 22:47:22 +0100, Roger Leigh wrote:
> > On Sat, May 12, 2012 at 03:55:24PM +0200, Guillem Jover wrote:
> > > One option would be to make dpkg-deb use an internal tar implementation,
> > > and add a file describing the attributes of the to be packaged files.
> > > That might make needing root privs (either through fakeroot or sudo)
> > > unneeded in most of the cases too.
> > 
> > I found that this functionality is already present in BSD tar,
> > according to the manpage.  You can provide a file containing
> > all the files to pack, plus their ownership and perms etc.,
> > rather than just specifying the files on the command-line.
> > 
> > bsdtar(1)
> > An input file in mtree(5) format can be used to create an output archive
> > with arbitrary ownership, permissions, or names that differ from existing
> > data on disk:
> [...]
> > -
> 
> Yeah, mtree is actually one of the things I've been having in mind
> when considering ways to store file metadata in the dpkg suite.
> 
> > I can't see an equivalent in GNU tar.  But BSD tar is available
> > in Debian.
> 
> This would imply BSD tar needs to be promoted to the Essential set
> alongside GNU tar, at which point I might as well just use an
> internal tar implementation.

Won't this only be needed for /packing/ the archive though?  Can't
any tar implementation still be used for unpacking?  Or would
dpkg-deb be constrained to a single tar for both operations?


Regards,
Roger

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


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

Re: on the use of chmod/chown in maintainer scripts

[Charles Plessy]

Le Sat, May 12, 2012 at 02:06:16PM -0700, Russ Allbery a écrit :
> 
> Usually because the UID is dynamically assigned and the user is created in
> the postinst, so there's no way for dpkg do do this at unpack.
> 
> You would need to apply permissions by name, not UID/GID, and you would
> need to create all users in preinst prior to unpack, which would require
> Pre-Depends on adduser with all the complexity that entails.  I haven't
> thought through that path to see if there are any other problems.

I see,

[please do not hesitate to answer on -mentors if I am getting trivial]

in some of my packages, I give the ownership on some directories in /var to
www-data without checking that the www-data group exists, but I guess it is
acceptable because it is globally allocated by base-passwd.

The way I do is simply to set the ownership when building the package, and let
dpkg do the rest for me.  For instance in emboss-explorer:

$ dpkg -c emboss-explorer_2.2.0-7_all.deb | grep -C 2 www-data
drwxr-xr-x root/root 0 2008-12-07 23:41 ./var/lib/
drwxr-xr-x root/root 0 2008-12-07 23:41 ./var/lib/emboss-explorer/
drwxr-xr-x www-data/www-data 0 2008-12-07 23:41 
./var/lib/emboss-explorer/output/
drwxr-xr-x root/root 0 2008-12-07 23:41 ./usr/
drwxr-xr-x root/root 0 2008-12-07 23:41 ./usr/lib/

Dpkg will not update permissions or ownership, but when creating the directory
it will apply the ones in the 'data' tar archive.  So if there was no package
released with wrong settings, I assume this is safe.  Or am I simply relying on
something undocumented and unwaranteed ?

Have a nice Sunday,

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


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

Re: on the use of chmod/chown in maintainer scripts

[Guillem Jover]

On Sun, 2012-05-13 at 01:17:35 +0100, Roger Leigh wrote:
> On Sun, May 13, 2012 at 02:10:13AM +0200, Guillem Jover wrote:
> > This would imply BSD tar needs to be promoted to the Essential set
> > alongside GNU tar, at which point I might as well just use an
> > internal tar implementation.
> 
> Won't this only be needed for /packing/ the archive though?  Can't
> any tar implementation still be used for unpacking?  Or would
> dpkg-deb be constrained to a single tar for both operations?

Well strictly speaking, yes it would only be needed for «dpkg-deb -b».
For dpkg --unpack, GNU tar is not even used, an internal implementation
is used instead, so that proper control of what's going on can be done.

But having dpkg-deb either use BSD tar only for extraction or for both
building and extraction would require for it to depend on BSD tar
being present, and I don't think we can get rid of GNU tar from
Essential at this point in time anyway, that's where my comment was
coming from.

And making dpkg-deb use either GNU or BSD tar depending on which one is
present does not seem too compelling.

Also because some of the code has to be written anyway for the
internal tar extractor, it should not be much work to add the building
side.

thanks,
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/20120513004805.ga9...@gaara.hadrons.org

Re: on the use of chmod/chown in maintainer scripts

[Russ Allbery]

Charles Plessy  writes:

> in some of my packages, I give the ownership on some directories in /var
> to www-data without checking that the www-data group exists, but I guess
> it is acceptable because it is globally allocated by base-passwd.

Right.

> Dpkg will not update permissions or ownership, but when creating the
> directory it will apply the ones in the 'data' tar archive.  So if there
> was no package released with wrong settings, I assume this is safe.  Or
> am I simply relying on something undocumented and unwaranteed ?

No, this is fine.  But it only works for globally-allocated IDs in
base-passwd.  If you instead need to dynamically generate a system user on
the fly and then set ownership of files to that user, which is a
reasonably common case, this is more complex.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87aa1crji4@windlord.stanford.edu

Re: Bug#672695: wordpress: no sane way for security updates in stable releases

[Russell Coker]

On Sun, 13 May 2012, Bernd Zeimetz  wrote:
> Being forced to upgrade to a new major version by a stable security support
> is nothing we should force our users to. Debian stable is known for
> (usually) painfree updates and bugfixes only, not for shipping completely
> new versions with a forced migration. Therefore - in my opinion - we
> should not ship wordpress in Wheezy, at least not until upstream handles
> such issues in a sane way.

Forcing users to manually install and update it or to use a package from 
outside Debian are also options that aren't good for users.

deb http://www.coker.com.au squeeze wordpress

I run my own repository of Wordpress packages at the above APT source.  That 
includes some Wordpress plugins that are licensed suitably for Debian but 
which have the same update issue.

One thing about Wordpress and it's plugins and themes is that you have to 
assume that every new release fixes some security issues.  They just don't 
document things well enough to allow you to assume otherwise.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201205131113.06212.russ...@coker.com.au