ltsp & pulseaudio

[Oleg]

  Hello.

In our organization we use ltsp on debian wheezy for our work. But we
get a non-working sound - mplayer freezes on playing and default sink stay
in suspend state forever, even if we run mplayer localy on thin station. The
problem is resolved if we add module-suspend-on-idle to pulseaudio. May be
we not alone in this problem. A patch for
/opt/ltsp/amd64/usr/share/ltsp/ltsp-init-common is attached.--- ltsp-init-common.old	2014-02-07 12:24:58.0 +0400
+++ ltsp-init-common	2014-02-07 12:25:18.0 +0400
@@ -34,6 +34,7 @@
 -L $PULSE_VOLUME_RESTORE \
 -L module-rescue-streams \
 -L "module-native-protocol-unix auth-anonymous=1" \
+-L "module-suspend-on-idle" \
 -n &
 ;;
 [Ff][Aa][Ll][Ss][Ee]|[Nn]|[Nn][Oo])

The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))

[Petter Reinholdtsen]

[Tollef Fog Heen]
> I'm pointing out why $all doesn't do what you want.  «$all» means «after
> everything else has started» and if you have two of those, you have a
> loop.  Loops are bugs.

That is a common misunderstanding of what $all means, and probably the
reason why insserv, systemd and openrc handle it differently.

$all was introduced by SuSe in the insserv package, which Debian also
uses to order init.d scripts, and for me that mean insserv is the one
defining what $all mean.  The $all facility is not defined in the LSB
3.1.0. In insserv, $all means after all scripts not depending on $all.
This is how it has been used in the two only distributions where the
facility has been in use (Debian and SuSe - are there others?).  I thus
suspect most or all init.d scripts in Debian today are based on how
insserv uses $all to order init.d scripts, given that this has been the
reference implementation when dependencies were introduced in init.d
scripts.

A better definition of $all, which to me make more sense than the
current definition in insserv, and which I suspect also would be less
confusing, could be "all scripts not depending directly or indirectly on
$all".  This would allow scripts depending on $all to also depend on
each other, and ensure correct ordering also in this case.

According to Tollef, systemd simply ignore $all, inserting scripts with
that dependency as if $all were not present.

And according to Thomas, OpenRC assume scripts depending on $all also
depend on other scripts depending on $all, conclude there is a loop and
try to break the loop at some random point in the perceived loop.

If I understand correctly, Upstart leave it to insserv to order init.d
scripts.

Here are some examples how this will lead to incorrect ordering.  Given
scripts A, B and C, where B depend on $all and C depend on $all, both
the correct order would be (A, B, C) and (A, C, B) - both are correct, B
and C can be started in parallel.  systemd can end up with the ordering
(B, A, C), (C, B, A), (B, C, A) and (C, A, B) in addition to the correct
ones, because it ignore $all and there are no other dependencies to take
into account.  OpenRC see a dependency loop B - C - B and will break it
at a random point, ending by chance up with on of the correct orderings.

Luckily there are not too many scripts with $all listed as its
dependency.  But those that use it, really need to run after most of the
scripts in the boot sequence, without being able to list them all.
rc.local is one example, which by definition should be among the last
scripts to run.

-- 
Happy hacking
Petter Reinholdtsen


-- 
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/2fl61orqntp.fsf...@ulrik.uio.no

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Daniel Leidert]

James McCoy wrote:

>In devscripts 2.13.3, uscan gained the ability to verify signature of
>the upstream tarball using a file debian/upstream-signing-key.pgp. In
>2.14.0, I added the ability to use armored keys and decided to move the
>files under debian/upstream/, an idea which had been suggested by a few
>people.
>
>This introduced a conflict with DEP-12 (c.f., #736760), which uses
>debian/upstream to track metadata about the upstream project. Tools
>like umegaya[0] and Debian Med's task list[1] use the information
>provided in this file.
[..]
>Part of the reason I chose to use debian/upstream/ is that an extensible
>location for upstream related information (similar in spirit to
>debian/source/) could be useful. 

I've really wondered, why you didn't use debian/source/ for this purpose
and introduced another directory? Why not put the key used to sign the
upstream source right into debian/source/?

[..]
>- Choosing a new name for DEP-12's file and updating the wording in
>DEP-12. My suggestion would be debian/upstream/metadata.

Sounds reasonable to me.

Regards, Daniel


-- 
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/trinity-c6d9bf47-e5f5-4226-83f2-ca74a6c60095-1391765572489@3capp-gmx-bs19

conflict between system user and normal user

[PICCA Frederic-Emmanuel]

Hello,

I am the maintainer of the tango package which contain the tango-db binary.

This tango-db provide a service called tango-db which connect to a mysql 
database.
I follow the debian-policy to create a dedicated system user for this services.
So I used the tango user which is the name of the community in charge of the 
tango-control system.

during the installation I generate a .my.cnf in the system user tango home 
which I set under
/usr/lib/tango in the package

now If a non-system user tango exist the home is not /usr/lib/tango but most 
probably /hom/tango.
so the installation process faild because it can not create the 
/usr/lib/tango/.my.cnf

What is the correct way to deal with this kind of problem ? I cannot find in 
the policy something
about conflict between system and non-system user.

thanks


Frederic


--
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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr

Re: conflict between system user and normal user

[Paul Wise]

On Fri, Feb 7, 2014 at 5:48 PM, Neil Williams wrote:

> Choose a name which is less likely to conflict, e.g. exim uses Debian-exim.

I think consensus was converging on prefixing an underscore for system
users (_foo) last time we discussed this.

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

Re: conflict between system user and normal user

[Neil Williams]

On Fri, 7 Feb 2014 08:57:32 +
PICCA Frederic-Emmanuel  wrote:

> Hello,
> 
> I am the maintainer of the tango package which contain the tango-db
> binary.
> 
> This tango-db provide a service called tango-db which connect to a
> mysql database. I follow the debian-policy to create a dedicated
> system user for this services. So I used the tango user which is the
> name of the community in charge of the tango-control system.

Choose a name which is less likely to conflict, e.g. exim uses Debian-exim.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

re: conflict between system user and normal user

[peter green]

What is the correct way to deal with this kind of problem ? I cannot find in 
the policy something
about conflict between system and non-system user.
  
I don't think there is much that can reall be done to fix the 
fundamental problem which is that system users and regular users have to 
live in the same namespace causing a risk of conflicts.


There are two things I can see you could do to impreove the situation 
with your package.
1: Fail early, it's better to have preinst fail than it is to start 
creating stuff with wrong permissions/ownership.
2: Choose a less generic name that is less likely to cause conflicts. Do 
you plan to use this user only for the db? if so tango-db might make 
sense, if not maybe something like tango-control-system.



--
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/52f4b091.5020...@p10link.net

Re: conflict between system user and normal user

[Jakub Wilk]

* Paul Wise , 2014-02-07, 17:52:

Choose a name which is less likely to conflict, e.g. exim uses Debian-exim.
I think consensus was converging on prefixing an underscore for system 
users (_foo) last time we discussed this.


Well, #248809 is still open…

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

Re: amd64 arch and optimization flags?

[peter green]

> this is dangerous it changes results, sometimes significantly (e.g. for
> complex numbers), only use if you don't care about correctness or have
> verified its still correct.

IME, audio processing software can get away with it. Csound and its 400+ 
library of opcodes has been built with this option and I have had no 
complaints yet.
  

Quite likely yes.
What is dangerous about this options? I see a warning in the gcc docs, 
  
Floating point numbers are an approximation of the real numbers. IEEE 
754 defines the format of the floating point numbers (on all common 
modern platforms) and also sets rules for how accurate that 
approximation should be and how exceptional conditions should be handled.


-ffast-math tells the compiler that you are more interested in speed 
than accuracy, repeatability and handling of exceptional conditions so 
it may use methods that don't follow the precise rules laid down in IEEE 754


>but how can I know if my program relies "on a precise definition of IEEE
>floating point"?
With difficulty, you really need to understand what exactly the code is 
doing and how senstive it is to accuracy in the calculations.



--
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/52f4b4a5.3070...@p10link.net

RE:conflict between system user and normal user

[PICCA Frederic-Emmanuel]

> I don't think there is much that can reall be done to fix the
> fundamental problem which is that system users and regular users have to
> live in the same namespace causing a risk of conflicts.

> There are two things I can see you could do to impreove the situation
> with your package.
> 1: Fail early, it's better to have preinst fail than it is to start
> creating stuff with wrong permissions/ownership.

Yes I nedd to faisl with a human comprehensible error explaining that the 
requested users
is already there but that is not a system user.

> 2: Choose a less generic name that is less likely to cause conflicts. Do
> you plan to use this user only for the db? if so tango-db might make
> sense, if not maybe something like tango-control-system.


no this user will be used by all tango controls system daemon.
tango-db
tango-starter
tango-accesscontrol
...

no my question is should I provide a amigration plan from the current tango 
user ?

this package is already usedin production.

--
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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr

Re: The meaning of $all in init.d scripts dependencies (Was: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!))

[Thomas Goirand]

On 02/07/2014 05:22 PM, Petter Reinholdtsen wrote:
> And according to Thomas, OpenRC assume scripts depending on $all also
> depend on other scripts depending on $all, conclude there is a loop and
> try to break the loop at some random point in the perceived loop.

That is correct, however, the way it is done currently, it does
approximately what one would expect in Debian! :)

Anyway, that's not a clean implementation. So, thanks a lot for this
definition matching sysv-rc. So this may lead to newer code.

The author of lsb2rcconf (eg: Dmitry Yu Okunev) will work on it. What
will be done is scanning all LSB header scripts for $all, and fix the
conversion to the OpenRC internal format (at least that's what he wrote
on IRC).

Cheers,

Thomas Goirand (zigo)


-- 
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/52f4b801.7010...@debian.org

Re: conflict between system user and normal user

[Neil Williams]

On Fri, 7 Feb 2014 10:15:18 +
PICCA Frederic-Emmanuel 
wrote:

> > I don't think there is much that can reall be done to fix the
> > fundamental problem which is that system users and regular users
> > have to live in the same namespace causing a risk of conflicts.
> 
> > There are two things I can see you could do to impreove the
> > situation with your package.
> > 1: Fail early, it's better to have preinst fail than it is to start
> > creating stuff with wrong permissions/ownership.
> 
> Yes I nedd to faisl with a human comprehensible error explaining that
> the requested users is already there but that is not a system user.

Just use a generic name and be done with it.
 
> > 2: Choose a less generic name that is less likely to cause
> > conflicts. Do you plan to use this user only for the db? if so
> > tango-db might make sense, if not maybe something like
> > tango-control-system.
> 
> 
> no this user will be used by all tango controls system daemon.

The name should not be hardcoded - if it is, patch upstream in each
case and fix it. Don't waste your time and user time on a hacky
workaround - fix the code.


-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



signature.asc
Description: PGP signature

Re: Updating the Policy Editors delegation

[Joerg Jaspert]

Am 07.02.2014 11:24, schrieb Lucas Nussbaum:


The Debian Policy team defines Debian's technical framework, 
including

the structure and contents of the Debian archive


So, the FTPTeam just got that ripped out of their gut.
Which means we can stop doing NEW and in a slightly more extreme 
interpretation
even stop all our cronjobs. We are no longer the ones doing the 
contents,

so how could we accept anything?

The part about the structure is also very debatable, this has also been 
a part
of FTPMaster in the past. I can see a small point in sharing this with 
the team

that writes down Policy, but thats a small one.

I think someone here has not thought about this text.

--
bye Joerg


--
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/8672773d550158b3e52a4b605b55c...@mail.ganneff.de

Re: Updating the Policy Editors delegation

[Ansgar Burchardt]

Hi,

On 02/07/2014 11:24, Lucas Nussbaum wrote:
> The Debian Policy team defines Debian's technical framework, including
> the structure and contents of the Debian archive, design issues of the
> operating system, as well as technical requirements that all packages
> must satisfy.
> 
> The Debian Policy team also maintains the Debian Policy Manual and all
> the other policy documents released as part of the "debian-policy"
> package.

Besides the issue Joerg raised, do you change the Policy team's role
from /documenting/ consensus (as mentioned in Policy 1.3) to actually
/defining/ policy?

Ansgar


-- 
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/52f4c9ba.10...@debian.org

RE:conflict between system user and normal user

[PICCA Frederic-Emmanuel]

> Just use a generic name and be done with it.

sorry, what do you mean by generic ?

> The name should not be hardcoded - if it is, patch upstream in each
> case and fix it. Don't waste your time and user time on a hacky
> workaround - fix the code.


no, the name is not hard coded by the upstream. I start "daemon" with 
start-stop-daemon with this command

start-stop-daemon --start --quiet --chuid tango:tango --background \
--make-pidfile --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_ARGS \
|| return 2

So it is hardcoded in the package not by the mainstream author.

Cheers

Fred

--
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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr

Re: autopkgtest + chroot howto ? - Was: Re: Is it possible to run autopkgtest without a virtual machine ?

[Antonio Terceiro]

On Sun, Jan 26, 2014 at 06:09:51PM +0100, Martin Pitt wrote:
> I advise to use the schroot runner instead. schroots are easy to set
> up these days with mk-sbuild, and with some additional love (like
> installing and configuring apt-cacher-ng and symlinking
> /var/lib/schroot/union/overlay/ and /var/lib/schroot/unpack/ to /tmp/,
> and having /tmp on a tmpfs),  set up, tear down, and package
> installation are extremely fast.

This schroot tip is precious! I have just reduced the build time (which
was mostly spent installing dependencies -- I was already using
apt-cacher-ng) of a package from ~4min to ~30s!

But instead of symlinking /var/lib/schroot/union/overlay/¹ , I configured
my sbuild chroots adding

  union-overlay-directory=/dev/shm

¹ that would affect all my chroots, not only the ones I use for sbuild.
  I expected the non-sbuild ones to still be there after a reboot. ;-)

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Updating the Policy Editors delegation

[Lucas Nussbaum]

Hi,

On 07/02/14 at 12:55 +0100, Ansgar Burchardt wrote:
> On 02/07/2014 11:24, Lucas Nussbaum wrote:
> > The Debian Policy team defines Debian's technical framework, including
> > the structure and contents of the Debian archive, design issues of the
> > operating system, as well as technical requirements that all packages
> > must satisfy.
> > 
> > The Debian Policy team also maintains the Debian Policy Manual and all
> > the other policy documents released as part of the "debian-policy"
> > package.
> 
> Besides the issue Joerg raised, do you change the Policy team's role
> from /documenting/ consensus (as mentioned in Policy 1.3) to actually
> /defining/ policy?

[ I addressed your question in my reply to Joerg:
http://lists.debian.org/20140207125848.ga16...@xanadu.blop.info ]

L.


-- 
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/20140207130230.ga17...@xanadu.blop.info

Re: Updating the Policy Editors delegation

[Lucas Nussbaum]

On 07/02/14 at 12:35 +0100, Joerg Jaspert wrote:
> Am 07.02.2014 11:24, schrieb Lucas Nussbaum:
> >The Debian Policy team defines Debian's technical framework,
> >including
> >the structure and contents of the Debian archive
> 
> So, the FTPTeam just got that ripped out of their gut.
> Which means we can stop doing NEW and in a slightly more extreme
> interpretation
> even stop all our cronjobs. We are no longer the ones doing the
> contents,
> so how could we accept anything?
> 
> The part about the structure is also very debatable, this has also
> been a part
> of FTPMaster in the past. I can see a small point in sharing this
> with the team
> that writes down Policy, but thats a small one.
> 
> I think someone here has not thought about this text.

Given the discussion that followed the previous delegation update, I
tried to make sure that this one wouldn't raise any concerns, so I
assure you that I thought about this text. :-)

Additionally, that text was sent for review to 8 people:
- Ian, as the one who raised the concerns about the previous version
- the Debian project secretary and his assistant
- the policy editors delegates
- Zack, as the DPL who wrote the previous version of the delegation

None of them had any concerns with the text.

But, since you think that this delegation can be interpreted as
conflicting with the ftpmasters delegation, let me clarify.
[ what follows might be too precise for a delegation text, the goal here
is to give an idea of the general spirit through some examples ]

Policy editors define Debian's technical framework, which is
documented in the Debian Policy Manual. That includes deciding on
things such as which archive areas (main, contrib, non-free) are
needed in the archive [that's *structure*], and define the general
rules about what goes in each section [that's *contents*]. They
also define the list of priorities (required, important, etc.)
[*structure*] and define the criteria for each priority
[*contents*].
Regarding sections (admin, text, python, etc.), they delegate
the decisions on maintaining the list of sections, and their
respective contents, to the archive maintainers (see Policy, 2.4). 

FTP masters maintain the archive. They decide how files and
directories are organized on Debian archive repositories, provided
that this does not conflict with the general framework defined by the
Policy editors.
They also decide, for each package, whether the suggestion made by
the maintainer (on archive area, priority, section, etc.) is a
valid one, by implementing and interpreting what is defined by the
Policy Editors, and in the DFSG (e.g. what is acceptable in 
main/contrib/non-free). They are also responsible for the general
consistency of the archive.


On 07/02/14 at 12:55 +0100, Ansgar Burchardt wrote:
> Besides the issue Joerg raised, do you change the Policy team's role
> from /documenting/ consensus (as mentioned in Policy 1.3) to actually
> /defining/ policy?

Yes. See the email from the Secretary on that issue [1]:
> This means that delegations should take care not to perscribe any
> particular process, or method for working that a delegate should adhere
> to. It is up to the delegate(s) to form a team and to produce a process
> themselves. It is, of course required as above that delegates should
> attempt to implement good technical decisions and/or follow consensus
> opinion.
[1] https://lists.debian.org/debian-project/2014/01/msg00054.html

If I delegate "defining policy" to the Policy Editors, I cannot at the
same time require that they will do that by following consensus, as that
would prescribe a particular process (8.2). However, as per constitution
8.3, Policy Editors "[..] should [...] follow consensus opinion."

More concretely, If they were considering changes that impact the work
of ftpmasters, it would expected from them to discuss those changes
beforehand with ftpmasters. Policy Editors have a track record of
seeking consensual positions, so I would be extremely surprised if they
did not do that.

There's also the question of the split of roles between the Policy
Editors and the Technical Committee:
The Policy Editors are in charge of the initial and detailed design of
the technical policy.
If there's disagreement, the issue can be brought to the technical
committee (which requires a simple majority to rule on technical
policy, see 6.1.1).


I would like to add something else:
I don't think that one should read delegations in search of loopholes that
would give some team more powers than what is generally understood.
Writing delegations that are at the same time not too prescriptive, and
descriptive enough, is already quite hard. It would be near-impossible to
write them as strict legal texts that avoid all loopholes, while still not 
making
them too prescriptive.
What matters is the general spirit. Requests for clarification are welcomed,
as well as, generally, talking with teams that are impacted or have an impact
on one's work.

Lucas


-- 

Re: autopkgtest + chroot howto ? - Was: Re: Is it possible to run autopkgtest without a virtual machine ?

[Julian Taylor]

On Fri, Feb 7, 2014 at 2:09 PM, Antonio Terceiro wrote:

> On Sun, Jan 26, 2014 at 06:09:51PM +0100, Martin Pitt wrote:
> > I advise to use the schroot runner instead. schroots are easy to set
> > up these days with mk-sbuild, and with some additional love (like
> > installing and configuring apt-cacher-ng and symlinking
> > /var/lib/schroot/union/overlay/ and /var/lib/schroot/unpack/ to /tmp/,
> > and having /tmp on a tmpfs),  set up, tear down, and package
> > installation are extremely fast.
>
> This schroot tip is precious! I have just reduced the build time (which
> was mostly spent installing dependencies -- I was already using
> apt-cacher-ng) of a package from ~4min to ~30s!
>
> But instead of symlinking /var/lib/schroot/union/overlay/¹ , I configured
> my sbuild chroots adding
>
>   union-overlay-directory=/dev/shm
>
>
>
you can archive similar speeds without a tmpfs using eatmydata, just stick
LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
in your rc equivalent.
This is also significantly faster than using dpkg --force-unsafe-io.

Using mount options that reduce failure safety on the partition/subvolume
holding the chroot build folder also helps a bit (nobarrier,
data=writeback, commit=3600 etc.)

Bug#738008: ITP: gap-openmath -- OpenMath phrasebook for GAP

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: gap-openmath
  Version : 11.2.0
  Upstream Author : Alexander Konovalov 
* URL : http://www.gap-system.org/Packages/openmath.html
* License : GPL
  Programming Lang: GAP
  Description : OpenMath phrasebook for GAP

GAP is a system for computational discrete algebra with particular
emphasis on computational group theory, but which has already proved
useful also in other areas.

This package allows GAP to import and export mathematical objects
encoded in OpenMath, for the purpose of exchanging them with other
applications that are OpenMath enabled.


-- 
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/20140207135435.13730.774.report...@nen.dnsalias.org

Bug#738011: ITP: gap-scscp -- SCSCP protocol in GAP

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: gap-scscp
  Version : 2.1.4
  Upstream Author : Alexander Konovalov 
  Steve Linton 
* URL : http://www.gap-system.org/Packages/scscp.html
* License : GPL
  Programming Lang: GAP
  Description : SCSCP protocol in GAP

GAP is a system for computational discrete algebra with
particular emphasis on computational group theory, but
which has alreadyproved useful also in other areas.

This package implements the Symbolic Computation Software
Composability (SCSCP) Protocol for GAP.


-- 
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/20140207140530.13910.11227.report...@nen.dnsalias.org

Bug#738039: ITP: arden -- specificity control for read alignments using an artificial reference

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: arden
  Version : 1.0
  Upstream Author : Sven H. Giese 
* URL : http://sourceforge.net/projects/arden/
* License : BSD
  Programming Lang: Python
  Description : specificity control for read alignments using an artificial 
reference
 ARDEN (Artificial Reference Driven Estimation of false positives in NGS
 data) is a novel benchmark that estimates error rates based on real
 experimental reads and an additionally generated artificial reference
 genome. It allows the computation of error rates specifically for a
 dataset and the construction of a ROC-curve. Thereby, it can be used to
 optimize parameters for read mappers, to select read mappers for a
 specific problem or also to filter alignments based on quality
 estimation.


Remark: This package is maintained by the Debian Med team and the
packaging is available at 
  git://anonscm.debian.org/debian-med/arden.git


-- 
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/20140207152440.10429.86805.report...@mail.an3as.eu

Re: Updating the Policy Editors delegation

[Joerg Jaspert]

Am 07.02.2014 13:58, schrieb Lucas Nussbaum:


>The Debian Policy team defines Debian's technical framework,
>including the structure and contents of the Debian archive
So, the FTPTeam just got that ripped out of their gut.
Which means we can stop doing NEW and in a slightly more extreme
interpretation even stop all our cronjobs. We are no longer the
ones doing the contents, so how could we accept anything?



The part about the structure is also very debatable, this has also
been a part of FTPMaster in the past. I can see a small point in
sharing this with the team that writes down Policy, but thats a 
small

one.

Given the discussion that followed the previous delegation update, I
tried to make sure that this one wouldn't raise any concerns, so I
assure you that I thought about this text. :-)
Additionally, that text was sent for review to 8 people:
- Ian, as the one who raised the concerns about the previous version
- the Debian project secretary and his assistant
- the policy editors delegates
- Zack, as the DPL who wrote the previous version of the delegation


And no one of the team thats babysitting the archive... :)


Policy editors define Debian's technical framework, which is
documented in the Debian Policy Manual.


Which is a change to the past, but you explain that one elsewhere.


That includes deciding on things such as which archive areas
(main, contrib, non-free) are needed in the archive [that's 
*structure*],

and define the general rules about what goes in each section
[that's *contents*]. They also define the list of priorities
(required, important, etc.) [*structure*] and define the criteria for
each priority [*contents*].



Regarding sections (admin, text, python, etc.), they delegate
the decisions on maintaining the list of sections, and their
respective contents, to the archive maintainers (see Policy, 2.4).


So a delegate delegates again, right.
Ok, basically what we did with the release team (and then they got DPL 
delegated),
backports (and then...). Fine, team can give away rights they have to 
others.



FTP masters maintain the archive. They decide how files and
directories are organized on Debian archive repositories, provided
that this does not conflict with the general framework defined by the
Policy editors.
They also decide, for each package, whether the suggestion made by
the maintainer (on archive area, priority, section, etc.) is a
valid one, by implementing and interpreting what is defined by the
Policy Editors, and in the DFSG (e.g. what is acceptable in
main/contrib/non-free). They are also responsible for the general
consistency of the archive.


With (my) plain english, the delegation reads different than the 
explanation.
That does need a redefined structure/content and leads to reactions 
like

my mail. Or what we had on IRC.


I would like to add something else:
I don't think that one should read delegations in search of loopholes 
that

would give some team more powers than what is generally understood.


"Generally understood" in a project as widely dispersed as others can 
be
very different for people. I haven't even read it searching for 
loopholes.
The different understanding of what content/structure mean in this 
context
between you and me show that its very easy to have a different reading 
of it.

I do think this should be clarified in the official delegation.

--
bye Joerg


--
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/f207979946c69708a6ed4c070608c...@mail.ganneff.de

Unreleased libraries

[Pau Garcia i Quiles]

Hello,

I am interested in packaging Skia ( https://code.google.com/p/skia/ ), the
2D library used in Chromium, Firefox and others. I need it because a
package I maintain (witty) is replacing GraphicsMagick with Skia.

I went to Skia's download page and... found there is none: Skia does not
make releases, tags, or anything like that. You download from Subversion
and the svn revision is all you have.

Is there a policy on how to package software that does not make releases?

http://en.wikipedia.org/wiki/Skia_Graphics_Engine
https://code.google.com/p/skia/

Thank you

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[heroxbd]

Sergey B Kirpichev  writes:

> http://packages.qa.debian.org/m/monit.html
> Usually, you want to start this service last and stop first.

The question is, before or after rc.local?


-- 
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/86ha8avpsh@moguhome00.in.awa.tohoku.ac.jp

Re: Unreleased libraries

[Michael Shuler]

On 02/07/2014 10:25 AM, Pau Garcia i Quiles wrote:

Is there a policy on how to package software that does not make releases?


A version similar to skia_0.0-1~svnr1234 would allow an upstream version 
of i.e. 0.1 (if they ever release) to supersede your packaged version. 
It should also allow you to upgrade via new svn version 
(0.0-1~svnr1235), as well as new packaging of same svn version 
(0.0-2~svnr1234).  Please, correct me, if there is a better method, here!


--
Kind regards,
Michael


--
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/52f50cd4.90...@pbandjelly.org

Re: Unreleased libraries

[Pau Garcia i Quiles]

On Fri, Feb 7, 2014 at 5:41 PM, Michael Shuler wrote:


> Is there a policy on how to package software that does not make releases?
>>
>
> A version similar to skia_0.0-1~svnr1234 would allow an upstream version
> of i.e. 0.1 (if they ever release) to supersede your packaged version. It
> should also allow you to upgrade via new svn version (0.0-1~svnr1235), as
> well as new packaging of same svn version (0.0-2~svnr1234).  Please,
> correct me, if there is a better method, here!
>
>
That's exactly what I had thought: 0.0-somenumber~svn123, where
"somenumber" is the soversion. Runtime packager for each soversion in other
to allow coinstallation, development packages, etc.

I have also noticed Firefox includes Skia in its source package, although
it may be justified because they heavily patch Skia. Icedove (Thunderbird)
and XULRunner also include their own version of Skia.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Unreleased libraries

[Andreas Beckmann]

On 2014-02-07 17:25, Pau Garcia i Quiles wrote:
> Is there a policy on how to package software that does not make releases?

You usually make up your own upstream version number, either
revision-based or date-based or both. Just ensure you use a version that
sorts before any later upstream release. Not having looked at skia at
all, I would suggest using as upstream version

0~svn12345  (if you tarred up revision 12345)
0~svn2014.02.07  (if you tarred up a snapshot today)
0~svn2014.02.07.r12345  (both)

or whatever you like. Note that the "0~" prefix will sort before e.g.
0.1 (or 0.0.0.0.1 or whatever), just in case upstream makes a release
some day, so you don't get into trouble having a "later" version in
Debian already.

And if upstream already did a release (or plans to) you would do
something like this to package a snapshot:

1.2.3+svn45678  (if the last upstream release was 1.2.3)
1.2.3~~svn45678  (if the last release was 1.2.2 and what you are
packaging is more like a pre-alpha-release candidate of 1.2.3 than a
followup to 1.2.2, note the double tilde '~~', this will allow you to
package 1.2.3~rc4 later on if upstream makes that available and finally
1.2.3 as the final release.

Start the debian revision with '-1' as usual.


If your upstream is git, you don't have monotonically increasing
revision numbers, but (unordered) commit hashes. I usually use something
based on 'git describe' as that gives you a number of commits since a
reference tag in addition to a release.

E.g. git describe returns 0.56-24-gffe37cd which is
--g
and I would version the snapshot as 0.56+git24-gffe37cd.


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/52f50f53.3090...@debian.org

Re: Unreleased libraries

[Jonas Smedegaard]

Quoting Michael Shuler (2014-02-07 17:41:56)
> On 02/07/2014 10:25 AM, Pau Garcia i Quiles wrote:
> > Is there a policy on how to package software that does not make releases?
> 
> A version similar to skia_0.0-1~svnr1234 would allow an upstream version 
> of i.e. 0.1 (if they ever release) to supersede your packaged version. 
> It should also allow you to upgrade via new svn version 
> (0.0-1~svnr1235), as well as new packaging of same svn version 
> (0.0-2~svnr1234).  Please, correct me, if there is a better method, here!

Here's a slightly shorter (and therefore arguably better, since you 
asked) scheme:

  skia_0-1~svnr1234


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Ian Jackson]

Chris Knadle writes ("Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo 
Cruz"):
...
> Well, here's the typical scenario:
> 
>- maintainer stops maintaining a package, for whatever reason,
>  and doesn't respond to communication... for a long time.
> 
>- things change, the package you use that the maintainer had previously
>  maintains breaks, or gets very old compared to upstream that 
>  compatibility issues arise.
> 
> What are your options?  [...]

My approach, if I wanted the package, would be to send an Intent to
Adopt email.  If the maintainer does not object then I would make an
upload making myself the maintainer (or co-maintainer).

If the maintainer does object then presumably you can have a
conversation with them.  If all they do is say "no" to ITA but don't
actually do anything else, then I think you should ask the TC.

Ian.


-- 
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/21237.4935.218758.343...@chiark.greenend.org.uk

Re: Unreleased libraries

[Pau Garcia i Quiles]

On Fri, Feb 7, 2014 at 5:52 PM, Andreas Beckmann  wrote:


> If your upstream is git, you don't have monotonically increasing
> revision numbers, but (unordered) commit hashes. I usually use something
> based on 'git describe' as that gives you a number of commits since a
> reference tag in addition to a release.
>
> E.g. git describe returns 0.56-24-gffe37cd which is
> --g
> and I would version the snapshot as 0.56+git24-gffe37cd.
>
>
For git-based projects, I usually use a timestamp + commit id, e. g.
0.56+git201402061828-gffe37cd. Slightly longer but easier to understand and
sorts as expected.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: Unreleased libraries

[Eugene Zhukov]

My apologies if something isn't right with this email, I'm writing from my 
phone. 
> On 7.2.2014, at 18.25, Pau Garcia i Quiles  wrote:
> 
> Hello,
> 
> I am interested in packaging Skia ( https://code.google.com/p/skia/ ), the 2D 
> library used in Chromium, Firefox and others. I need it because a package I 
> maintain (witty) is replacing GraphicsMagick with Skia.
> 
> I went to Skia's download page and... found there is none: Skia does not make 
> releases, tags, or anything like that. You download from Subversion and the 
> svn revision is all you have.
> 
Have you tried asking them (the upstream) for a tag?
I have a couple of times asked politely for a tag from some upstreams and was 
lucky to get one, even though the upstream hasn't had a tag in years.

Eugene

Re: Wanted: perl package home for condorcet computation script

[Ian Jackson]

Ian Jackson writes ("Re: Wanted: perl package home for condorcet computation 
script"):
> Paul Wise writes ("Re: Wanted: perl package home for condorcet computation 
> script"):
> > On Mon, Feb 3, 2014 at 11:46 PM, Ian Jackson wrote:
> > > It would like to live in some Debian package.
> > 
> > devscripts seems like the ideal package. I guess some folks would want
> > to use it for meeting times and team decisions.
> 
> CCing the devscripts list.  Hi, devscripts maintainers.  What do you
> think ?

Hi, James, I was wondering if you had an opinion about this proposal.
Would my condorcet vote counter fit into devscripts ?

The dependencies have grown a bit: now it depends on
Graph::Writer::GraphViz too, so, indirectly, on graphviz.

Ian.


-- 
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/21237.6317.578832.638...@chiark.greenend.org.uk

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Chris Knadle]

On Friday, February 07, 2014 17:09:27 Ian Jackson wrote:
> Chris Knadle writes ("Re: Packaging of stunnel / MIA for Luis Rodrigo
> Gallardo Cruz"): ...
> 
> > Well, here's the typical scenario:
> >- maintainer stops maintaining a package, for whatever reason,
> >  and doesn't respond to communication... for a long time.
> >
> >- things change, the package you use that the maintainer had previously
> >  maintains breaks, or gets very old compared to upstream that
> >  compatibility issues arise.
> > 
> > What are your options?  [...]
> 
> My approach, if I wanted the package, would be to send an Intent to
> Adopt email.  If the maintainer does not object then I would make an
> upload making myself the maintainer (or co-maintainer).
> 
> If the maintainer does object then presumably you can have a
> conversation with them.  If all they do is say "no" to ITA but don't
> actually do anything else, then I think you should ask the TC.

Yes this sounds very reasonable as well.
Thanks -- this helps!

  -- Chris

--
Chris Knadle
chris.kna...@coredump.us

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

Re: Upstart support for LSB headers (Two line init.d scripts? Sure, that will work!)

[Sergey B Kirpichev]

On Sat, Feb 08, 2014 at 01:41:18AM +0900, hero...@gentoo.org wrote:
> Sergey B Kirpichev  writes:
> 
> > http://packages.qa.debian.org/m/monit.html
> > Usually, you want to start this service last and stop first.
> 
> The question is, before or after rc.local?

Doesn't matter)  rc.local shouldn't be used by local
admin to start services from.  Why not use usual init-script?

On Sat, Feb 08, 2014 at 01:43:59AM +0900, hero...@gentoo.org wrote:
> Sergey B Kirpichev  writes:
> 
> > So, lets start services first, then start monitoring.  Do we want to
> > play races with sysvinit?  No.  Now can you see the point?
> 
> We don't have to race it: by telling service managers other than monit
> (sysvinit, openrc, sysv-rc, etc. etc.)  to leave what monit concerns
> alone can do the trick.

Yes, that's easy.  For human.


-- 
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/20140207181402.ga12...@darkstar.order.hcn-strela.ru

Virtual "fizmo" package

[Christoph Ender]

Hi all,

I’m currently thinking about creating a virtual package for "fizmo". This
was a single package in squeeze, got split up into "fizmo-ncursesw" and
"fizmo-console" in wheezy, keeping a transitional "fizmo" package in
oldlibs (which pulled in fizmo-ncursesw so far). "fizmo-sdl" is still in
beta but might be released this year.

I'd like to drop the transitional "fizmo" package for the jessie release
and provide a virtual package of the same name instead (this will give
people trying to install fizmo give at least a clue why the package
apparently isn't there anymore and the alternatives system looks like a
good way for managing a link to the installed binary).

Section 3.6 of the policy manual mentions (via the virtual package list)
that new virtual package names should be agreed on in debian-devel, so:
Any thoughts on this?


Thanks in advance,
Christoph.


--
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/de58d6c0-5254-48ce-b79b-0b09057ea...@spellbreaker.org

Re: Virtual "fizmo" package

[Andreas Beckmann]

On 2014-02-07 19:22, Christoph Ender wrote:
> Section 3.6 of the policy manual mentions (via the virtual package list)
> that new virtual package names should be agreed on in debian-devel, so:

I think your use case is covered by the

  (except privately, amongst a cooperating group of packages)

clause.


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/52f52a34.7040...@debian.org

Re: Unreleased libraries

[Jonas Smedegaard]

Quoting Pau Garcia i Quiles (2014-02-07 17:51:47)
> I have also noticed Firefox includes Skia in its source package, 
> although it may be justified because they heavily patch Skia. Icedove 
> (Thunderbird) and XULRunner also include their own version of Skia.

Thanks for noticing!

Please report that to the security team, as documented at 
https://wiki.debian.org/EmbeddedCodeCopies

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: conflict between system user and normal user

[Andreas Beckmann]

On 2014-02-07 09:57, PICCA Frederic-Emmanuel wrote:
> during the installation I generate a .my.cnf in the system user tango home 
> which I set under
> /usr/lib/tango in the package

That should be under /var, not /usr, especially if you dynamically
generate stuff there.

And if that is a configuration file that is supposed to be editable by
the admin, it should live in /etc (maybe using a different name, and/or
a subdirectory), symlinked from the tango users home.


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/52f52c59.4010...@debian.org

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Andreas Tille]

Hi,

On Fri, Feb 07, 2014 at 10:32:52AM +0100, Daniel Leidert wrote:
> I've really wondered, why you didn't use debian/source/ for this purpose
> and introduced another directory? Why not put the key used to sign the
> upstream source right into debian/source/?

+1
 
Kind regards

Andreas.

-- 
http://fam-tille.de


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

Re: Packaging of stunnel / MIA for Luis Rodrigo Gallardo Cruz

[Sebastian Reichel]

Hi Rodrigo,

On Fri, Feb 07, 2014 at 10:21:12AM -0800, Rodrigo Gallardo wrote:
> I do!

ah, nice to hear from you.

> I have been extremely remiss in my duties, and I have let ego keep
> me from accepting it.
>
> I have orphaned stunnel and all of my other packages. Feel free to
> NMU/take over as needs be. I will submit my formal resignation as
> soon as I get the machine with my private key out of from under all
> those half-read books.
> 
> Meanwhile, please accept my apologies for not doing this earlier.

No harm done. Thanks for the work you did for the Debian project :)
It's really appreciated.

-- Sebastian


signature.asc
Description: Digital signature

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[Andreas Tille]

Hi Paul,

On Fri, Feb 07, 2014 at 01:18:09PM +0800, Paul Wise wrote:
> Another project that looks at DEP-12 metadata is DUCK, the Debian URL
> checker. I think it looks at DEP-12 stuff as a source of URLs to
> check.

Is this some vote to keep the file debian/upstream?

> There are other issues with uscan/DEP-12;

I do not think we should discuss DEP-12 issues in this thread.  If you
really want to discuss it please use another thread.  Just for
additional explanation:

> debian/watch is duplicated in the Watch field in DEP-12 debian/upstream.

Charles did clarify this.  I personally never understood why we should
keep a copy of some code hanging around somewhere.  I never maintained
this (optional) field since I thought you can always auto-generate this
field from existing (+tested +maintained) debian/watch file if (at all)
uscan would regard debian/upstream instead of debian/watch.
 
> The Homepage field from debian/control is duplicated in DEP-12 
> debian/upstream.

I also ignored this (optional) field since for me it makes no sense
to have the very same information at different places before there is
some slight tendency for acceptance.  Finally some cme tricks could
do the conversion later.
 
> umegaya doesn't support packages where there is no VCS. Not sure if
> the blends site has the same issue?

The Blends tools are using data from UDD exclusively.  So if it is not
UDD it is not seen.

Kind regards

   Andreas.
 

-- 
http://fam-tille.de


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

Re: Unreleased libraries

[Steve McIntyre]

Pau Garcia i Quiles wrote:
>
>I am interested in packaging Skia ( https://code.google.com/p/skia/ ), the
>2D library used in Chromium, Firefox and others. I need it because a
>package I maintain (witty) is replacing GraphicsMagick with Skia.
>
>I went to Skia's download page and... found there is none: Skia does not
>make releases, tags, or anything like that. You download from Subversion
>and the svn revision is all you have.
>
>Is there a policy on how to package software that does not make releases?

In general, I think others have given you good advice. In the case of
skia, is is actually useful to package it? Upstream explicitly don't
do releases, semmingly because they don't believe in them at all. The
recommended way of using it is to embed a copy - ugh!

(Background: I've contributed code to skia myself in the past...)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/


-- 
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/e1wbrz0-00074x...@mail.einval.com

RE:conflict between system user and normal user

[PICCA Frederic-Emmanuel]

Hello,

I dig a little bit in the debian documentation, and I found this snipset
in the section 9.2 of securing-debian-howto [1]

It is interesting to see the code used to create a system user.
But the step 4 bother me

   usermod -c "$SERVER_NAME" \
   -d $SERVER_HOME   \
   -g $SERVER_GROUP  \
  $SERVER_USER

So it seems that this code update silently the user home during the package 
installation.

Is it a good practice ?

[1] https://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html


Cheers

Fred

--
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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr

Re: Bug#735134: perl: rename(1) is ancient

[Dominic Hargreaves]

On Mon, Feb 03, 2014 at 09:28:03AM +, Jonathan Dowland wrote:
> Hi Gregor,
> 
> On Sun, Feb 02, 2014 at 07:31:02PM +0100, gregor herrmann wrote:
> > It's the package for the CPAN File::Rename distribution, and
> > therefore named accordingly to
> > https://www.debian.org/doc/packaging-manuals/perl-policy/ch-module_packages.html#s-package_names
> > in Debian.
> 
> Thanks for pointing me at that. It seems to me this makes sense for
> libraries but not for end-user binaries.
>  
> > (Cf. also
> > http://pkg-perl.alioth.debian.org/policy.html#package_naming_policy )
> 
> This seems to agree since it suggests end-user binary packages should
> not follow the libfoo-bar-perl scheme.
> 
> [ as a side-note, if the perl group are following the latter, then
>   a minor-severity bug against policy to update the former to reflect
>   that practise sounds like it might be in order. I'll do this unless
>   anyone objects. ]
> 
> I guess there are common situations where you have both an end-user
> binary and a perl module in the same source, and you might not want
> to split that into two binary packages (if they're very small or 
> something), however that doesn't appear to be the case here.

Yeah, I think I agree that this package should be named 'rename' since
it will be predominantly used as an standalone utility rather than
library. (I'm assuming noone is going to object to such a generic name).
I'll file a new bug for that.

Thanks,
Dominic.


-- 
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/20140207230756.gl26...@urchin.earth.li

Bug#738138: ITP: php-file-find -- Class that facilitates the search of filesystems

[Francois-Regis Vuillemin]

Package: wnpp
Severity: wishlist
Owner: "Francois-Regis Vuillemin" 

* Package name: php-file-find
  Version : 1.3.2
  Upstream Author : Sterling Hughes 
* URL : http://pear.php.net/package/File_Find/
* License : PHP
  Programming Lang: php
  Description : Class that facilitates the search of filesystems

File_Find, created as a replacement for its Perl counterpart, also named
File_Find, is a directory searcher, which handles, globbing, recursive
directory searching, as well as a slew of other cool features.

php-file-find is a dependency (rec.) of horde  5.1.5


-- 
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/20140208005125.2356.29917.report...@graves.miradou.com

Re: Conflict between debian/upstream (DEP-12) & debian/upstream/ (uscan)

[James McCoy]

On Fri, Feb 07, 2014 at 10:32:52AM +0100, Daniel Leidert wrote:
> James McCoy wrote:
> >Part of the reason I chose to use debian/upstream/ is that an extensible
> >location for upstream related information (similar in spirit to
> >debian/source/) could be useful. 
> 
> I've really wondered, why you didn't use debian/source/ for this purpose
> and introduced another directory? Why not put the key used to sign the
> upstream source right into debian/source/?

debian/source/ is for content related to the source package.

debian/upstream/ would be for content related to upstream.

There's a distinct separation there and as the signing key is, IMO,
obviously upstream metadata it's not appropriate for debian/source/.
The only relation it has to the source package is that it's used to
verify one component of the source package.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: Wanted: perl package home for condorcet computation script

[James McCoy]

On Fri, Feb 07, 2014 at 05:32:29PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Wanted: perl package home for condorcet computation 
> script"):
> > Paul Wise writes ("Re: Wanted: perl package home for condorcet computation 
> > script"):
> > > On Mon, Feb 3, 2014 at 11:46 PM, Ian Jackson wrote:
> > > > It would like to live in some Debian package.
> > > 
> > > devscripts seems like the ideal package. I guess some folks would want
> > > to use it for meeting times and team decisions.
> > 
> > CCing the devscripts list.  Hi, devscripts maintainers.  What do you
> > think ?
> 
> Hi, James, I was wondering if you had an opinion about this proposal.
> Would my condorcet vote counter fit into devscripts ?

It didn't seem to fit your criterion about dependencies, but if you're
fine with that, then sure.

> The dependencies have grown a bit: now it depends on
> Graph::Writer::GraphViz too, so, indirectly, on graphviz.

Given the more niche role of the script, the dependencies probably won't
be part of the "default install" set anyway, so that shouldn't be a big
deal.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Re: amd64 arch and optimization flags?

[Vincent Lefevre]

On 2014-02-06 13:44:30 +, Felipe Sateler wrote:
> On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote:
> > On 06.02.2014 00:39, Jaromír Mikeš wrote:
> >> -ffast-math
> > 
> > this is dangerous it changes results, sometimes significantly (e.g. for
> > complex numbers), only use if you don't care about correctness or have
> > verified its still correct.
> 
> IME, audio processing software can get away with it. Csound and its 400+ 
> library of opcodes has been built with this option and I have had no 
> complaints yet.
> 
> What is dangerous about this options? I see a warning in the gcc docs, 
> but how can I know if my program relies "on a precise definition of IEEE 
> floating point"?

Some specific floating-point algorithms (in particular those that
"emulate" additional precision by controlling the roundings) will
not work with it.

An example is https://www.vinc17.net/software/sipe.h when using
SIPE_FLOAT (though I haven't tested).

For floating-point algorithms that just assume that operations are
performed with some rounding error but without going further on
IEEE 754 properties and do not use special values (infinities and
signed zeros), -ffast-math may work. But -ffast-math enables
-fassociative-math and -freciprocal-math, which may increase the
expected rounding errors in some cases.

Note also that using -ffast-math may introduce security holes, for
instance if an algorithm that fills an array converges slower with
it, yield a buffer overflow. This is more or less what happened for

  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6499
  https://bugzilla.mozilla.org/show_bug.cgi?id=358569

(the cause wasn't -ffast-math, but involved reduced accuracy).

Be careful with audio processing software, if the audio files can
come from a remote source.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20140208030153.ga20...@xvii.vinc17.org

Re: Updating the Policy Editors delegation

[Charles Plessy]

Le Fri, Feb 07, 2014 at 01:58:48PM +0100, Lucas Nussbaum a écrit :
> 
> Additionally, that text was sent for review to 8 people:
> - Ian, as the one who raised the concerns about the previous version
> - the Debian project secretary and his assistant
> - the policy editors delegates
> - Zack, as the DPL who wrote the previous version of the delegation

Precision: I wrote it, with input of Stefano and the active Policy editors,
using some texts from wiki.debian.org as a starting material.

Thank you Lucas for your efforts, but I think that the best would have been to
ignore the complaints that led you to change the delegation.

 - The complainers are not doing the Policy work,
 - they own work was not affected by the Policy work done under the
   wording they complained about, and
 - they did not propose a better wording.

Unsurprisingly, the result of trying to satisfy the complainers about their
non-problem is to increase division in the project.

The hardline that is being taken by the complainers is removing any interest to
the delegation texts.  Basically, the Policy delegates are in charge of the
Policy, the Release delegates are in charge of the Release, the Archive
delegates are in charge of the Archive, etc.  Some may see it more do-o-cratic,
but I find this a step backwards.

Have a nice week-end,

-- 
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/20140208040147.ga18...@falafel.plessy.net

Bug#738151: ITP: python-hplefthandclient -- HP LeftHand/StoreVirtual HTTP REST Client

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-hplefthandclient
  Version : 1.0.1
  Upstream Author : Kurt Martin 
* URL : https://pypi.python.org/pypi/hplefthandclient
* License : Apache-2.0
  Programming Lang: Python
  Description : HP LeftHand/StoreVirtual HTTP REST Client

 This is a Client library that can talk to the HP LeftHand/StoreVirtual Storage
 array. The HP LeftHand storage array has a REST web service interface.
 .
 This client library implements a simple interface to talk with that REST
 interface using the python httplib2 http library.


-- 
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/20140208061359.6486.10657.report...@buzig.gplhost.com

Re: Virtual "fizmo" package

[Christoph Ender]

Am 07.02.2014 um 19:47 schrieb Andreas Beckmann :

> On 2014-02-07 19:22, Christoph Ender wrote:
>> Section 3.6 of the policy manual mentions (via the virtual package list)
>> that new virtual package names should be agreed on in debian-devel, so:
> 
> I think your use case is covered by the
>  (except privately, amongst a cooperating group of packages)
> clause.
> 
> Andreas


You're right, thank you.

Christoph.


-- 
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/2f8129e8-f13c-4e92-8ee9-52eb09ace...@spellbreaker.org

Bug#738156: ITP: python-klein -- Python Twisted Web micro-framework inspired by Flask

[Brian Campbell]

Package: wnpp
Severity: wishlist
Owner: Brian Campbell 

* Package name: python-klein
  Version : 0.2.3
  Upstream Author : David Reid 
* URL : https://github.com/twisted/klein
* License : MIT (Expat)
  Programming Lang: Python
  Description : Python Twisted Web micro-framework inspired by Flask

 Klein is a micro-framework for developing production ready web
 services with python.  It is 'micro' in that it has an incredibly
 small API similar to bottle and flask.  It is not 'micro' in that it
 depends on things outside the standard library.  This is primarily
 because it is built on widely used and well tested components like
 werkzeug and Twisted.


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