RFC: Realtime system (audio) group

[Adrian Knoth]

Hi!

[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]

As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.

We can call this group "rtaudio", but maybe somebody prefers a more
generic name, e.g., "realtime". Maybe there is already such a group.


WDYT?


Cheers


--
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/4f1fda28.9020...@drcomp.erfurt.thur.de

Bug#657291: ITP: ruby-mab -- a templating engine for writing HTML pages in pure Ruby

[Paul van Tilburg]

Package: wnpp
Severity: wishlist
Owner: Paul van Tilburg 

* Package name: ruby-mab
  Version : 0.0.1
  Upstream Author : Magnus Holm 
* URL : http://github.com/camping/mab
* License : MIT
  Programming Lang: Ruby
  Description : a templating engine for writing HTML pages in pure Ruby

 With Mab, HTML is generated by mapping method calls to HTML elements,
 object attributes to element classes or HTML IDs and block arguments to
 the contents of the elements.
 .
 This engine is an alternative to ERb which weaves the two languages
 together.  It is also a replacement for templating languages which use
 primitive languages that blend with HTML.
 .
 Mab is almost fully backward compatible with the Markaby library.

Note that the package description is almost the same as that of
libmarkaby-ruby, because Mab is going to replace it due to major license
problems with the Markaby.



-- 
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/20120125105359.29990.78550.report...@density.luon.net

Re: RFC: Realtime system (audio) group

[Simon McVittie]

On 25/01/12 10:32, Adrian Knoth wrote:

As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.


rtkit (packaged in Debian) seems a safer way to do this than group-based 
privileges + setuid root. It doesn't just hand out realtime priorities, 
it also has a watchdog thread with a higher priority than the rt 
application itself, so it can carry out an emergency de-prioritization 
on the rt application to get control back to your shell/UI if the system 
becomes unresponsive.


If you have PolicyKit, rtkit defaults to letting you have rt priorities 
if and only if you are logged in locally (gdm, kdm, getty etc., but not 
ssh); as with all PK services, the policy is configurable (so a local 
admin could give this privilege to the audio or users group, or a new 
group). I'm not sure what its fallback policy is if you don't have PK.


The Debian packages for pulseaudio used to create a pulse-rt group which 
granted access to realtime priority for the user's instance of the 
pulseaudio daemon (basically what you're proposing, but Pulse-specific), 
but since 0.9.16 it's just recommended rtkit instead.


Having to add users to an ever-increasing number of groups so they can 
run applications as intended seems like an anti-pattern, if there's a 
sensible default (e.g. involving "only if logged-in locally") with 
configuration that can override it; this is why PK exists.


S


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

Re: RFC: Realtime system (audio) group

[Bastian Blank]

On Wed, Jan 25, 2012 at 11:32:08AM +0100, Adrian Knoth wrote:
> [background story: pro-audio applications run with POSIX realtime
> priorities to meet low-latency deadlines. We ship
> /etc/security/limits.d/audio.conf in the jackd packages to grant rt
> privileges to the audio group]

Why does jackd not grant _itself_ RT priority? It can grant itself
CAP_SYS_NICE, which allows arbitrary mangling of priorities.

It could still limit the usage for users with the audio group and just
drop the capability of the user is not in this group.

Bastian

-- 
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown


-- 
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/20120125114347.ga20...@wavehammer.waldi.eu.org

Re: RFC: Realtime system (audio) group

[Bastian Blank]

On Wed, Jan 25, 2012 at 11:38:18AM +, Simon McVittie wrote:
> rtkit (packaged in Debian) seems a safer way to do this than
> group-based privileges + setuid root.

Why does it use setuid and not CAP_SYS_NICE?

Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2


-- 
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/20120125114442.gb20...@wavehammer.waldi.eu.org

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:44 PM, Bastian Blank wrote:


On Wed, Jan 25, 2012 at 11:38:18AM +, Simon McVittie wrote:

rtkit (packaged in Debian) seems a safer way to do this than
group-based privileges + setuid root.


Why does it use setuid


It doesn't use setuid root. Simon has wrongly assumed this.


--
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/4f1fec99.4060...@drcomp.erfurt.thur.de

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:43 PM, Bastian Blank wrote:


[background story: pro-audio applications run with POSIX realtime
priorities to meet low-latency deadlines. We ship
/etc/security/limits.d/audio.conf in the jackd packages to grant rt
privileges to the audio group]


Why does jackd not grant _itself_ RT priority? It can grant itself
CAP_SYS_NICE, which allows arbitrary mangling of priorities.


   # setcap cap_sys_nice,cap_ipc_lock+eip /usr/bin/jackd

Works, but is hardly an improvement. It's either a stability risk (if
not limited) or:


It could still limit the usage for users with the audio group and just
drop the capability of the user is not in this group.


Which would still require the user to be part of a special group. The
audio group can't be used for this, as it would again combine "access to
sound card" and "have realtime permissions" as described in #656910.

So we're back at how to name this group. ;)


Cheers


--
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/4f1ff2ea.8090...@drcomp.erfurt.thur.de

Candidates for removal from testing

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


We are considering removing the following packages from testing as
they have unfixed RC bugs filed against them.  The packages can be
found in the attached dd-list (or at [0]).

The packages have been selected based on the following criteria:
 - The package had at least one RC bug without activity for the past
   14 days.
   - If a bug is assigned to multiple packages, both packages will
 be affected[1].
 - The RC bug affects both unstable and testing.
 - The affected package does not have any reverse dependencies in
   testing.

These tools[2] are rather new and therefore we have randomly chosen 10
packages from the originally generated list.  These 10 packages were
manually verified to fit the criteria listed above.  The full list
is available at [3], but has not been manually verified.


If the relevant RC bugs in the affected packages are not dealt with
before the 11th of Feb., the packages will be removed from testing.
Note that "dealt with" may also include downgrading a
severity-inflated bug or fixing affected versions in the BTS.


Thanks,
Niels (on behalf of the Release Team)

[0] http://release.debian.org/~nthykier/selected-dd-list-2012-01-25

[1] Examples include #561903 (at submission time; it was later
reassigned to a single package).

[2] The tools are available from:

svn://svn.debian.org/svn/collab-qa/rc-buggy-leaf-packages

[3] http://release.debian.org/~nthykier/rc-buggy-leaf-pkgs-dd-list-2012-01-25

Note: Some people have confused "dconf" and "d-conf" in this list.  The
former is an RC-buggy leaf package.  The latter is also RC buggy, but
has plenty of reverse dependencies (and is therefore not listed).  In
the particular case, they happen to share the same RC bug, #627508.


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

iQIcBAEBCAAGBQJPH/QfAAoJEAVLu599gGRCqd0QALCtineFuTCR5QQxKHrYACFm
Cnvidc5YkGOeP7EaxHwZOlXqM1cu0mVTZB6aRG2Ig0Qq++lV2ptKNScNUyBYDjDJ
9+c4njgAmD1Xf0MC/uBrwcapokJciq32YdKWqUKiNYHyrzauNdja1vNRtLrZiAZ7
2X3SXTy3qAW6qtGiPNdHa/vhd6a2c141Va7dzLQhy6YrAmsb2hARVP8DgM1ZInXc
u5C3dT5BPu8EoldvS/+PQU/HX/Xu1cpUDdqqKaWmyQLwGv2wHgyUXYe0vnrJG+2Z
50HhaFOZrKaqVbFY8uLCfcbRwZm2Y3WqvBI2SkZi1+z8mJ2epQEUfEU1gVHZ0SO0
N0MjfZTYOU68XhMREZ3Z/LsCcwHXJizqbzO4K+fMQE6MuxyYrAARxsfwIO+0Wfof
SE7vJzeJow7RS0C4tNFAblkd665C0nioQXiWmFiqXY6NRW4Ncmu3Aa3i96/pqhtL
uxmVS7cenIwdGsyPXPloDmKTu8niZpbbGTXvyLltA7b6bg8Eu/LnQ8T0bMG1mRgz
r7SvhyonpT5YZgTNDFhBrdUZijELWuvnFegJwPTH8Ph/mXDwM3iApm+GFJXgut8g
6nuAfmoSAw2ZT1ffliB7Eo4eSJXUaMbS1bN9z8JSxa54s6SSLrYeUN4GAQwFiKwg
pwIaprJFCC8zsWLioEAQ
=FbK3
-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/20120125122400.d24ca20131...@thykier.net

Re: Lock down of io.debian.net

[Alexander Reichle-Schmehl]

Hi!

Am 25.01.2012 13:02, schrieb Aurelien Jarno:

> we noticed that due to some misconfiguration all home directories of 
> io.debian.net have been exposed through HTTP.
> 
> As an immediate action, the machine has been locked down for further 
> inspection.
[..]
> We sincerely apologize for the inconvenience.

Having used that machine a couple of times already (even so I only have
some dotfiles there) I can assure you that there is no inconvenience at all!

On the contrary:  Thanks taking this issue so seriously!


Best regards,
  Alexander


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

Re: RFC: Realtime system (audio) group

[Adrian Knoth]

On 01/25/2012 12:38 PM, Simon McVittie wrote:


As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.

To make these two independent, we'd need to use a different (new?) group
for realtime priorities.

rtkit (packaged in Debian) seems a safer way to do this than group-based
privileges + setuid root.


As already pointed out, there is no setuid binary.


it also has a watchdog thread with a higher priority than the rt
application itself, so it can carry out an emergency de-prioritization
on the rt application to get control back to your shell/UI if the system
becomes unresponsive.


RT CPU bandwidth is limited to 95% these days. No need for a watchdog
anymore.


If you have PolicyKit, rtkit defaults to letting you have rt priorities
if and only if you are logged in locally (gdm, kdm, getty etc., but not


Is there something like

   "If you're logged in locally, I'll grant you RT prios"?

that does not require the application to use dbus? So to say, "@local"
PAM magic or inherited from gdm/kdm/getty?

Can policykit do this? This would be a good compromise between "make it
work for the local user without messing with groups", but still leaving
enough freedom for the experienced if ssh is required.

Note that this would change the default ulimits if logged in locally.
We'd end up with every local user having RT priorities and more or less
unlimited memory locking. AFAIK, it's what OSX does, but it might
require some discussion if it's desired to have the same in Debian.



Cheers


--
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/4f1ff63a.1000...@drcomp.erfurt.thur.de

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Antonio Terceiro]

Don Armstrong escreveu isso aí:
> On Mon, 23 Jan 2012, Jakub Wilk wrote:
> > I normally advocate using upstream name for source package name
> > (even if it's a single binary package and the binary package would
> > have a different name due to $LANGUAGE policy).
> 
> If you are only building one binary package, the source package should
> have the same name. The exception to this guideline is when the binary
> package name is expected to change over the lifetime of the source
> package. [For example, if the binary name contains a soname.]
> 
> Otherwise you can end up with confusing cases where a package with
> source foo builds binary bar, and binary foo is built by source bar.
> 
> The language guidelines for binary packages exist to avoid cluttering
> the package namespace, and they should generally be applied to source
> packages too.

Another argument in favor of using the same name for source and binary
packages: suppose there is "libfoo", and independent bindings for Perl,
Python and Ruby, all called "foo", and that "foo" is unique in their
respective upstream language-specific namespaces (CPAN/PyPi/Rubygems);
which one gets to use the 'foo' source package name in Debian? First
come first serve won't work.

BTW DEP-5 proposes a explicit field in debian/copyrigh for the upstream
name of packages, so machine discovery of this information should not
be too hard.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Bug#657067: ITP: futures -- backport of concurrent.futures package from Python 3.2

[Jakub Wilk]

* Antonio Terceiro , 2012-01-25, 10:12:
Another argument in favor of using the same name for source and binary 
packages: suppose there is "libfoo", and independent bindings for Perl, 
Python and Ruby, all called "foo", and that "foo" is unique in their 
respective upstream language-specific namespaces (CPAN/PyPi/Rubygems); 
which one gets to use the 'foo' source package name in Debian?


None of them, of course.

This is an argument for naming source packages in a sane way when your 
upstream for some reasons could do that himself... Not much to do with 
$binarypackagename==$sourcepackagename, really.


--
Jakub Wilk


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

Re: cross-build-essential

[DrEagle]

Hi all,

I have not so time available too, but :
- I need a good cross toolchain solution for armel/armhf.
- I use debian on my sheevas and desktops
- I have allready made a port of DoudouLinux Debian based system on
Genesi SmartBook
- I have a lot of others projects still in progress or in standby...

Le 23/01/2012 16:28, Wookey a écrit :
> However right now no-one is really working on this much. Hector is
> busy with armhf stuff (and a new job). I'm working on sbuild/buildd
> multiarch cross-building. 
> 
> If anyone wants to take the glory by actually making this work (it
> probably isn't very hard at this stage) you are very welcome. The
> debian-embedded list is the place where this stuff gets discussed.

I can be interested by taking the glory by making things works.
- What are the needed stuff ?
- How can I start study what had been already done ?
- What's next to be acomplish ?
- Who can help in taking needed informations, best practice, and stuff
that I may forget ?

SeeYouSoon...
---
DrEagle



signature.asc
Description: OpenPGP digital signature

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

[Richard Sweeney]

> * Package name: edgar
>   Version : 0.94
>   Upstream Author : Richard Sweeney 
> * URL : http://www.parallelrealities.co.uk/p/legend-of-edgar.html
> * License : GPL2+

>Please note that not everything is GPL2+. The music is certainly not, it is in
>fact not even distributable in non-free since most songs do not have any
>license information, and some of them even lack copyright notices. Although I
>believe all graphics has been created from scratch and is in fact covered by
>the GPL, you should check it out to be sure. With Edgar, you can probably run
>the game (maybe with minor tweaks) without music.

(Stumbled across this today)

The code is GPL and the gfx and data is CC BY-NC-SA 3.0. Removing the sound 
should
be quite straightforward. If you do want to add this game to Debian, let me 
know and I
can supply a patch for the latest release (0.97) to allow the game to run 
without sound.

Richard

  

Re: Candidates for removal from testing

[Luk Claes]

On 01/25/2012 01:24 PM, Niels Thykier wrote:
> 
> We are considering removing the following packages from testing as 
> they have unfixed RC bugs filed against them.  The packages can be 
> found in the attached dd-list (or at [0]).

For anyone who is not online the list of 10 packages is:

David Ammouial 
   irssi-plugin-xmpp

Debian FreeSmartphone.Org Team 
   fso-abyss

Fabio Tranchitella 
   phpldapadmin

Gerfried Fuchs 
   qcake

Heiko Stuebner 
   fso-abyss (U)

Peter Miller 
   libexplain

Philipp Matthias Hahn 
   mytop

Piotr Roszatycki 
   ldapdns

Ruben Molina 
   scidavis

Sebastian Dröge 
   bcov

Stuart R. Anderson 
   lsb-appchk3

Cheers

Luk


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

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

[Adam Borowski]

On Wed, Jan 25, 2012 at 05:49:00PM +, Richard Sweeney wrote:
> 
> > * Package name: edgar
> >   Version : 0.94
> >   Upstream Author : Richard Sweeney 
> > * URL : 
> > http://www.parallelrealities.co.uk/p/legend-of-edgar.html
> > * License : GPL2+
> 
> >Please note that not everything is GPL2+. The music is certainly not, it is 
> >in
> >fact not even distributable in non-free since most songs do not have any
> >license information, and some of them even lack copyright notices. Although I
> >believe all graphics has been created from scratch and is in fact covered by
> >the GPL, you should check it out to be sure. With Edgar, you can probably run
> >the game (maybe with minor tweaks) without music.
> 
> (Stumbled across this today)
> 
> The code is GPL and the gfx and data is CC BY-NC-SA 3.0. Removing the sound 
> should
^^
> be quite straightforward. If you do want to add this game to Debian, let me 
> know and I
> can supply a patch for the latest release (0.97) to allow the game to run 
> without sound.

You can't mix -NC- licenses with GPL.  You can't have them in Debian proper,
too.  The most you can do is to put the graphics and data in non-free, then
the code in contrib, at least unless some free graphics+data exist.

The sound, being indistributable, cannot be included at all.


-- 
// 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: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

[Jon Dowland]

On Wed, Jan 25, 2012 at 07:40:55PM +0100, Adam Borowski wrote:
> You can't mix -NC- licenses with GPL.  You can't have them in Debian proper,
> too.  The most you can do is to put the graphics and data in non-free, then
> the code in contrib, at least unless some free graphics+data exist.

I took that as read...


-- 
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/20120125224001.GA884@pris

Bug#657395: RFP: cinnamon -- Cinnamon desktop

[Carlos C Soto]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org



Package name: cinnamon
Version: 1.2
URL: http://cinnamon.linuxmint.com/
License: GPL
Description: Cinnamon is a Linux desktop which provides advanced innovative 
features and a traditional user experience.


The desktop layout is similar to Gnome 2.
The underlying technology is forked from Gnome Shell.
The emphasis is put on making users feel at home and providing them with an easy 
to use and comfortable desktop experience.


There are a PPA for Ubuntu:
https://launchpad.net/~merlwiz79/+archive/cinnamon-ppa 



It has been packaged for Fedora, OpenSUSE, ArchLinux and other distros:
http://cinnamon.linuxmint.com/?page_id=61

The source code is available at the Git:
https://github.com/linuxmint/Cinnamon



--
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/4f2089c8.6060...@sia-solutions.com

Re: Bug#653813: ITP: edgar -- The Legend of Edgar platform game

[Guus Sliepen]

On Wed, Jan 25, 2012 at 05:49:00PM +, Richard Sweeney wrote:

> The code is GPL and the gfx and data is CC BY-NC-SA 3.0.

This is the first time I've heard a mention of a CC license. There is nothing
in the source tarball mentioning a Creative Commons license. If you really mean
it to be CC BY-NC-SA 3.0, you have to clearly specify that in the source and
binary packages you are distributing.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bits from the piuparts maintainers

[jidanni]

I just hate those packages that leave candy bar wrappers all over the
carpet! Go piuparts! Catch them all! And let's hope the highway patrol
will keep those litterbugs off the roads forever! Why just today I had
to manually clean up some more "dog droppings" from 2002. Yuck.


-- 
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/87zkdbjpbj@jidanni.org

every day 54 of the top 1 million sites switch to Debian

[jidanni]

Re: Debian Project News - January 23rd, 2012
> Debian "is also the fastest growing operating system at the moment:
> every day 54 of the top 1 million sites switch to Debian"
At this rate in
$ expr 100 / 54 / 365
50
years, we will take over the world :-)


-- 
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/87sjj3jos6@jidanni.org

ITP wordpress-wptouch

[Russell Coker]

Description: Wordpress WPTouch mobile phone plugin
 Wordpress plugin to provide an alternate view of the blog that suits Android
 phones, iPhones, and other small mobile devices.  The view may be switched
 between phone view and regular view by the user.

GPL license.

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

Currently available at the above APT repository.

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

Bug#657405: ITP: mediagoblin -- web application for sharing pictures and videos

[Clint Byrum]

Package: wnpp
Severity: wishlist
Owner: Clint Byrum 

* Package name: mediagoblin
  Version : 0.2.0
  Upstream Author : Various persons, GNU
* URL : http://mediagoblin.org/
* License : GPL-3+
  Programming Lang: Python
  Description : web application for sharing pictures and videos

 The perfect tool to show and share your media!  Building tools to
 empower the world through decentralization!  Built for extensibility.
 Part of the GNU project and devoted to user freedom.
 .
 Built with awesome technology (Python, Celery, MongoDB, and more)
 with a clean design for a future that's more than just image galleries.



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

Re: Candidates for removal from testing

[Paul Wise]

On Thu, Jan 26, 2012 at 2:41 AM, Luk Claes wrote:
> On 01/25/2012 01:24 PM, Niels Thykier wrote:
>>
>> We are considering removing the following packages from testing as
>> they have unfixed RC bugs filed against them.  The packages can be
>> found in the attached dd-list (or at [0]).
>
> For anyone who is not online the list of 10 packages is:

In future, perhaps the initial mail could contain the dd-list and also
be CCed/BCCed to the relevant $pack...@packages.qa.debian.org
addresses?

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caktje6gzor2uz+yaecwkfghqdjt+h3dq_uvd7xrs6pfwcac...@mail.gmail.com

Re: ITP wordpress-wptouch

[Paul Wise]

On Thu, Jan 26, 2012 at 8:22 AM, Russell Coker wrote:

> ITP wordpress-wptouch

Please actually file an ITP bug against wnpp:

http://www.debian.org/devel/wnpp/#l1

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6EUuieP_O_XCFv4fBK32e4p-0jXw9FucnOn=ciuvhj...@mail.gmail.com

Do symbols make sense for C++

[Russ Allbery]

I'm currently working on the Policy modification to document (and
recommend) use of symbols instead of shlibs, but I'd only personally used
symbols with C libraries.  Today I decided that I should try adding a
symbols file to a C++ library, particularly if I'm going to recommend
everyone do it.  I tried this exercise with xml-security-c, which is, I
think, a reasonably typical C++ library.  Not the sort of core C++ library
that would sit at the center of the distribution, but a random software
package that's in Debian because other things use it.

The experience was rather interesting, and I ended up uploading the new
version without a symbols file and continuing to just use shlibs.  That's
for the following reasons:

1. The generated symbols file was HUGE.  Hundreds of lines.  This is a
   marked difference from the typical C symbols file, which is of quite
   manageable size.  Some of that is that the library provides a lot of
   different classes, but some of it is that C++ just generates a lot of
   exported symbols.  There's no way that I could do what I would do with
   a C library and understand those symbols, why they're there, and
   whether they are likely to have changed between revisions.

2. Generating a reasonable symbols file was a pain.  Generating an
   unreasonable symbols file that just contains all of the mangled symbols
   is largely mechanical and uninteresting, but that symbols file doesn't
   seem to me to convey useful information.  So I did some scripting to
   translate the symbols back with c++filt, and add (c++) tags, and then
   try to understand what I was looking at and figure out whether I should
   sort the symbols list because the default sort is by mangled name,
   which is meaningless.  This is a rather unappealing process.  It's not
   particularly difficult, but it's very awkward and feels like it's
   missing vital tools.

3. The resulting symbols file is incomprehensible to someone without
   strong knowledge of C++.  It's full of opaque entries that don't make
   sense to the non-C++ programmer, wihch I suspect is a substantial
   number of people who package C++ libraries for Debian.  I know enough
   C++ from school that I can evaluate security fixes, make simple
   patches, and review upstream changes, and I think that's all that
   should be needed to package things for Debian.  But I'm deeply
   uncomfortable producing a symbols file on my own that contains entries
   for things that I know nothing about and cannot evaluate when they've
   last changed, like "non-virtual thunk to FooClass::~FooClass@Base".

4. Once I had a symbols file that resulted in a successful build and that
   I could have uploaded, I started thinking about how I was going to
   maintain it.  With a C program, I would change the symbols file
   versions when the underlying function implementation changes in a way
   that may not offer eqiuvalence, similar to bumping shlibs.  I realized
   that I was going to have no idea when that happened, and the only way
   that I would maintain the symbols file would be to either trust
   upstream to maintain ABI equivalence and therefore only change the
   symbols file when upstream changes the SONAME, or not trust upstream to
   maintain ABI equivalence and therefore change all the versions with
   each new upstream release.  That gives me exactly the same semantics as
   a shlibs file, so what's the point in having a symbols file?

5. The exported symbols of the library contained many symbols that
   obviously weren't really from that library, but instead were artifacts
   of the C++ compilation process, things like instantiations of
   std::vector.  Do those go into the symbols file?  Do they change from
   architecture to architecture?  If they disappear again, is that
   actually an ABI break?  How do I know?  It's all very mysterious, and
   while shlibs provides the same semantics as just ignoring this, at
   least I'm not then including in the package data, generated by me,
   things that I'm just blindly ignoring.

I came away from this experience thinking that I should revise the Policy
amendment to say that symbols files are really for C libraries and for C++
libraries with either a tightly maintained symbol export list or
maintained by a C++ expert, and that most C++ library maintainers should
just not bother with this and use shlibs, bumping the shlibs version or
not based on their impression of how good upstream is at maintaining ABI
equivalence.

But that feels like a result contrary to what I had previously thought was
the intended direction, so I wanted to ask the Debian development
community as a whole: am I missing something?  Are these symbols files
actually useful?  Am I missing some trick to make them useful?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia

Re: Do symbols make sense for C++

[Raphael Hertzog]

Hi,

On Wed, 25 Jan 2012, Russ Allbery wrote:
> 4. Once I had a symbols file that resulted in a successful build and that
>I could have uploaded, I started thinking about how I was going to
>maintain it.  With a C program, I would change the symbols file
>versions when the underlying function implementation changes in a way
>that may not offer eqiuvalence, similar to bumping shlibs.  I realized
>that I was going to have no idea when that happened, and the only way
>that I would maintain the symbols file would be to either trust
>upstream to maintain ABI equivalence and therefore only change the
>symbols file when upstream changes the SONAME, or not trust upstream to
>maintain ABI equivalence and therefore change all the versions with
>each new upstream release.  That gives me exactly the same semantics as
>a shlibs file, so what's the point in having a symbols file?

The main benefit of the symbols file is that new symbols (API extension)
are listed with the version where they have been introduced. So that
seriously reduces the number of packages which would be affected by the
equivalent shlibs bump.

Otherwise I agree with you, maintainers of C++ libs are unlikely to be
able to (preemptively) detect when a given symbol should have had its
version bumped... so you should really trust upstream and hope to catch
API extension that preserve ABI in the upstream changelog.

> 5. The exported symbols of the library contained many symbols that
>obviously weren't really from that library, but instead were artifacts
>of the C++ compilation process, things like instantiations of
>std::vector.  Do those go into the symbols file?  Do they change from
>architecture to architecture?  If they disappear again, is that
>actually an ABI break?  How do I know?  It's all very mysterious, and
>while shlibs provides the same semantics as just ignoring this, at
>least I'm not then including in the package data, generated by me,
>things that I'm just blindly ignoring.

It's also very mysterious to me. :) But Modestas Vainius has still managed
to maintain symbols files for many KDE libraries. He might be able to tell
you more.

(He's also the one who implemented all the required support in
dpkg-gensymbols)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/


-- 
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/20120126075855.gl18...@rivendell.home.ouaza.com