Re: upstart: please update to latest upstream version

[Svante Signell]

On Mon, 2012-03-05 at 14:44 +0100, Marco d'Itri wrote:
> On Mar 05, Marc Haber  wrote:
> 
> > Should Debian restrict itself to being a Linux platform just to have
> > systemd?
> If it is worth it, yes.
> 
> Should Debian reject using  component> just to support toy ports which are used by a dozen of people?

It might have some truth in it today, maybe not tomorrow. Please refrain
from this kind of categoric statements. Do you have a crystal ball?

This kind of statement is similar to a statement made by Bill Gates.
Microsoft: "640K ought to be enough for anybody" It *was* *definitely*
said by Bill Gates. He said it at an early microcomputer trade show in
Seattle in mid 1981. Another famous statement is by Thomas J. Watson,
IBM, from 1943, "I think there is a world market for maybe five
computers"



-- 
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/1331022019.25378.25.ca...@hp.my.own.domain

Re: picking packages from repos was: debian-multimedia.org considered harmful

[Thomas Koch]

Andreas Tille:
> On Mon, Mar 05, 2012 at 04:42:50PM +0100, Reinhard Tartler wrote:
> > In summary, I can only advise everyone against enabling that
> > repository on any machine.
> 
> If I would have time to become a pkg-multimedia member I would try to
> establish installing multimedia applications via metapackages build be
> the Blends framework.  I would most probably drop some file
> 
>/etc/apt/preferences.d/01-disable-dmo.pref
> 
> in multimedia-config metapackage (where all other metapackages usually
> depend from).  This would enable those users who really know what they
> are doing picking singular packages via well defined preferences from
> d.m.o if needed and prevent users who blindly inject "random sources"
> inside their sources.list from killing their system.
Hi Andreas,

could you point me to the necessary documentation, please? I'd like to enable 
the non-free repo, but only pick a few packages from it. How can I do this?

This would also be useful to pick only a few packages from unstable, e.g. 
those that I maintain.

Regards,

Thomas Koch, http://www.koch.ro


-- 
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/201203060947.28896.tho...@koch.ro

Re: picking packages from repos was: debian-multimedia.org considered harmful

[Andreas Tille]

On Tue, Mar 06, 2012 at 09:47:28AM +0100, Thomas Koch wrote:
> could you point me to the necessary documentation, please? I'd like to enable 
> the non-free repo, but only pick a few packages from it. How can I do this?

man apt_preferences
 
> This would also be useful to pick only a few packages from unstable, e.g. 
> those that I maintain.

For instance I use

$ cat /etc/apt/preferences.d/01-debian-policy.pref 
/etc/apt/preferences.d/01-lintian.pref 
Package: debian-policy
Pin: release a=unstable
Pin-Priority: 605
Package: lintian
Pin: release a=unstable
Pin-Priority: 605

While my /etc/apt/preferences has lines like this

Package: *
Pin: release a=testing
Pin-Priority: 501

Package: *
Pin: release a=unstable
Pin-Priority: 50

Package: *
Pin: release a=experimental
Pin-Priority: 5
 

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/20120306090549.ga26...@an3as.eu

Re: upstart: please update to latest upstream version

[Wouter Verhelst]

On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> On Tue, Mar 06, 2012 at 08:07:37AM +0100, Wouter Verhelst wrote:
> > So far, I haven't seen any features in systemd that outweigh those. And
> > the fact that upstream is lazy and doesn't want to do this portability
> > thing shouldn't mean we should throw out our other ports.
> 
> Er, let's not call upstream lazy just because they don't want to do
> work that has no interest for themselves.

I don't see what else I should call them.

I'm not saying that being lazy is necessarily a bad thing, nor that they
must absolutely do this portability thing. But I do think that writing
portable software isn't that hard, and that not doing it is pure
lazyness.

Note that I consider "software which has more features on one platform
than it does on another, but that still has basic functionality on all
platforms" to be portable; but systemd doesn't even do that.

> We don't require Debian developers to do work for Debian
> (Constitution, 2.1.1), after all.

First, Lennert isn't a Debian developer.

Second, I'm not requiring anything of him.

All I'm saying is that if someone wants to do something for Debian, they
better not break other people's work in the process unless they have a
good reason. Replacing sysvinit with another implementation that doesn't
work on all our ports would fail that, and is therefore not something I
would consider acceptable.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120306091243.ga4...@grep.be

Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains

[Andreas Tille]

On Tue, Mar 06, 2012 at 10:23:33AM +0900, Norbert Preining wrote:
> On Di, 06 Mär 2012, Jonas Smedegaard wrote:
> > > the Blends framework.  I would most probably drop some file
> > > 
> > >/etc/apt/preferences.d/01-disable-dmo.pref
> > > 
> > > in multimedia-config metapackage (where all other metapackages usually 
> 
> And I would file a serious bug against that. There is no reasoning
> behind that is in any way reasonable.
> 
> Only because these are providing similar packages starting
> a "hunting down the enemies" race is irrational, or even worse,
> simply stupid.

In how far is it stupid that if a metapackage intends to install a set
of _Debian_ packages featuring multimedia tasks to make sure that really
these packages are installed while enabling a user to install, say
acrobat reader in addition without influencing the set of multimedia
packages available inside Debian?  It is not about hunting down anything
but installing reasonable preconfiguration - local admin can override
this for sure.

I wonder what criterion of serios bug would apply here.  Just for the
sake of interest because I do not intend to implement this personally.

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/20120306091502.gb26...@an3as.eu

Re: upstart: please update to latest upstream version

[Wouter Verhelst]

On Tue, Mar 06, 2012 at 07:23:53AM +, Philip Hands wrote:
> On Tue, 6 Mar 2012 08:07:37 +0100, Wouter Verhelst  wrote:
> 
> > So far, I haven't seen any features in systemd that outweigh those. And
> > the fact that upstream is lazy and doesn't want to do this portability
> > thing shouldn't mean we should throw out our other ports.
> 
> I know it's already been mentioned in this thread, but perhaps it bears
> repeating, that we use openssh, where the upstream effectively has the
> same attitude when it comes to portability code in their own source
> tree.  Despite that they happily work with the porting team to generate
> the version that everyone uses on Linux.
> 
> Is a similar approach not possible for systemd?

If we're going to include systemd and/or make it the default, it should be, as
far as I'm concerned.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/2012030609.ga3...@grep.be

Bug#662763: ITP: libaio-ocaml -- OCaml bindings for libaio (Linux kernel AIO access library)

[Goswin von Brederlow]

Package: wnpp
Severity: wishlist
Owner: Goswin von Brederlow 

Package name: libaio-ocaml
Version : 1.0~rc3
Upstream Author : Goswin von Brederlow 
URL : http://forge.ocamlcore.org/projects/libaio-ocaml/
Vcs-Git : 
git://anonscm.debian.org/pkg-ocaml-maint/packages/libaio-ocaml.git
Vcs-Browser : 
http://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/libaio-ocaml.git
License : LGPL-2.1 and link exception
Programming Lang: Ocaml + C
Description : OCaml bindings for libaio (Linux kernel AIO access library)

 This OCaml-library interfaces the libaio (Linux kernel AIO access
 library) C library. It can be used for fast asynchronous I/O.
 .
 Compared with the OCaml standard and Unix I/O functions this
 library:
  * does not block
  * does I/O in the background
  * calls a continuation when the I/O has completed



-- 
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/20120306090504.25581.4453.reportbug@frosties.localnet

Re: Unofficial repositories on 'debian' domains

[Thomas Goirand]

On 03/06/2012 03:55 PM, Paul Wise wrote:
> On Tue, Mar 6, 2012 at 3:44 PM, Stefano Zacchiroli wrote:
>
>   
>> Now, is anyone against publishing the list of debian.net entries and the
>> entry <-> registrant association (provided the above conditions are
>> met)?
>> 
> That is already published in DNS:
>
> pabs@chianamo ~ $ dig -t txt mentors.debian.net | grep TXT
> ;mentors.debian.net.  IN  TXT
> mentors.debian.net.   3593IN  TXT "Christoph Haas 
> "
> mentors.debian.net.   3593IN  TXT "PGP 9B26 F48E 6F2B 0A3F 7E33  
> E6B7
> 095E 77C5 79CC 6586"
>   
It's not *always* published.
Try with ipv6 or mozilla.debian.net for example.

Making this as a rule seems relevant and a good idea to me.
It'd be even better if we could publish a list instead of only
an individual if we want to (but still keep the PGP fingerprint).

Thomas


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

Re: A few observations about systemd

[Jon Dowland]

On Tue, Feb 28, 2012 at 07:18:51PM +0100, Christoph Egger wrote:
> 
> Uoti Urpala  writes:
> > I think it's quite arrogant of BSD users to expect others to work to
> > support their systems.
> 
> There's qute a difference between parts of debian expecting upstream to
> do the work and upstream hostily denying existing patches I'd say

If upstream don't want to support a non-Linux architecture that's their
business, their perogative, and really I don't think it's fair to describe
that as hostile at all.  Are we asking different standards from systemd
than we expect from core openssh?

-- 
Jon Dowland


-- 
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/20120306100110.GB27642@debian

Re: upstart: please update to latest upstream version

[Lars Wirzenius]

On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> > Er, let's not call upstream lazy just because they don't want to do
> > work that has no interest for themselves.
> 
> I don't see what else I should call them.

I see. Then I am afraid we need to agree to disgree. I don't agree
with anything you said in the mail I'm responding to, except the bit
about pizza. Given the total disagreement about acceptable behavior
or approach to portability, I don't think it's worth continuing this
sub-thread, either.


signature.asc
Description: Digital signature

Re: A few observations about systemd

[Jon Dowland]

On Sat, Feb 25, 2012 at 12:08:51AM +0100, Svante Signell wrote:
> > I think the fundamental problem is having kFreeBSD in Debian. It's too
> > much extra work and problems for limited benefit to a small number of
> > people. Holding things hostage with "you have to make this work on
> > kFreeBSD too or it won't be allowed at all" arguments will have negative
> > effects beyond just init systems.
> 
> Then you are not talking about Debian. Do you want to create your own
> distribution? Feel free to do that:)

Uoti's point here has long been recognised and accepted *within* Debian:
every architecture bears a cost.  The question as to whether the cost of
kFreeBSD is too much or not is, well, not universally agreed amongst
Debian developers.




-- 
Jon Dowland


-- 
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/2012030612.GA27642@debian

Re: Unofficial repositories on 'debian' domains

[Paul Wise]

On Tue, Mar 6, 2012 at 5:43 PM, Thomas Goirand wrote:

> It's not *always* published.
> Try with ipv6 or mozilla.debian.net for example.
>
> Making this as a rule seems relevant and a good idea to me.
> It'd be even better if we could publish a list instead of only
> an individual if we want to (but still keep the PGP fingerprint).

As I hinted at in the other part of my mail (that you stripped), it
isn't possible to mix CNAME and TXT records on the same domain. This
is why mozilla.debian.net doesn't have the TXT record, dunno about
IPv6 though.

I definitely would like to see the domains/owners and contact details
(lets add an LDAP field) exposed on db.debian.org.

-- 
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/caktje6e8ibb0fq-jwv+fjd0jhhmyo8hhsfawwj6z_g3pa2k...@mail.gmail.com

Re: Unofficial repositories on 'debian' domains

[Vincent Danjean]

Le 06/03/2012 01:56, Jonas Smedegaard a écrit :
> Debian now has a *changed* hard line against patent infringing software 
> - resulting in more codecs supported in official Debian packages.

Perhaps, it is time to look at each package in d-m.o and list all
that are now equals (or better ?) in term of functionality in Debian.
And then, ask christian if I really want to maintain these now useless
packages, if any?
But, of course, it is more work than just complaining on d-d. Any
volunteers ?

  Regards,
Vincent

PS: I use d-m.o myself, mainly for libdvdcss2 and acroread [when I
cannot read a PDF with my usual pdf readers (mainly xpdf and evince),
I try with acroread before complaining to the sender]

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
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/4f55e5c0.9010...@free.fr

Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains

[Norbert Preining]

On Di, 06 Mär 2012, Andreas Tille wrote:
> I wonder what criterion of serios bug would apply here.  Just for the
> sake of interest because I do not intend to implement this personally.

Too lazy to search for it, but overriding a configuration of a
system admin is for sure not allowed. If it would be, I can stop
caring of conffile upgrades ...

What if the next package decides do disable X, login, and whatever?
Is that policy conform?

Anyway, don't care for extending this rubbish discussion.

Norbert

Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094

FEAKLE (vb.)
To make facial expressions similar to those that old gentlemen make to
young girls in the playground.
--- Douglas Adams, The Meaning of Liff


-- 
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/20120306104052.gb24...@gamma.logic.tuwien.ac.at

Re: Unofficial repositories on 'debian' domains

[Jonas Smedegaard]

On 12-03-06 at 11:24am, Vincent Danjean wrote:
> Le 06/03/2012 01:56, Jonas Smedegaard a écrit :
> > Debian now has a *changed* hard line against patent infringing 
> > software - resulting in more codecs supported in official Debian 
> > packages.
> 
> Perhaps, it is time to look at each package in d-m.o and list all that 
> are now equals (or better ?) in term of functionality in Debian. And 
> then, ask christian if I really want to maintain these now useless 
> packages, if any?
> But, of course, it is more work than just complaining on d-d. Any 
> volunteers ?

Feel free to do so.  But I recommend to read this first: 
http://lists.debian.org/debian-devel/2012/03/msg00151.html


 - 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: Digital signature

Bug#662797: ITP: libfile-inplace-perl -- Perl module to ease editing a file in-place

[Salvatore Bonaccorso]

Package: wnpp
Owner: Salvatore Bonaccorso 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libfile-inplace-perl
  Version : 0.20
  Upstream Author : Chip Turner 
* URL : http://search.cpan.org/dist/File-Inplace/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to ease editing a file in-place

File::Inplace is a perl module intended to ease the common task of editing a
file in-place. Inspired by variations of perl's -i option, this module is
intended for somewhat more structured and reusable editing than command line
perl typically allows. File::Inplace endeavors to guarantee file integrity;
that is, either all of the changes made will be saved to the file, or none
will. It also offers functionality such as backup creation, automatic field
splitting per-line, automatic chomping/unchomping, and aborting edits
partially through without affecting the original file.



-- 
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/1331040995.66832.20692@elende

Re: upstart: please update to latest upstream version

[Jon Dowland]

On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 07:54:43AM +, Lars Wirzenius wrote:
> > Er, let's not call upstream lazy just because they don't want to do
> > work that has no interest for themselves.
> 
> I don't see what else I should call them.
> 
> I'm not saying that being lazy is necessarily a bad thing

It's a perjorative term and people could interpret it to mean bad.

> But I do think that writing portable software isn't that hard, and that not
> doing it is pure lazyness.

It's not about difficulty, systemd isn't not-portable simply because the
authors haven't got around to it yet; it fundamentally relies on a Linux-only
technology.

The features you've defended FreeBSD for (jails, ZFS) are not portable either;
which is to say, if you write software that depends on them, it won't work on
Linux.

-- 
Jon Dowland


-- 
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/20120306140800.GA31728@debian

Re: upstart: please update to latest upstream version

[Wouter Verhelst]

On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> The features you've defended FreeBSD for (jails, ZFS) are not portable either;
> which is to say, if you write software that depends on them, it won't work on
> Linux.

Very true.

However, the difference between the systemd position and the ZFS one is
that nobody's suggesting we throw out support for ext4, btrfs, or XFS
(just to name a few).

I don't mind adding support for systemd to Debian, and I don't even mind
making it the default on Linux. But if we end up with where the *only*
working init implementation in Debian isn't supported on kFreeBSD, then
we've done something wrong.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120306151242.gd15...@grep.be

Re: upstart: please update to latest upstream version

[Wouter Verhelst]

One more thing...

On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > But I do think that writing portable software isn't that hard, and that not
> > doing it is pure lazyness.
> 
> It's not about difficulty, systemd isn't not-portable simply because the
> authors haven't got around to it yet; it fundamentally relies on a Linux-only
> technology.

This is wrong. An init implementation is not fundamentally Linux-only.
No matter how they chose to implement it, no matter what they've ended
up with, it is fundamentally possible to write an init implementation
that will work on more than just Linux.

It is perfectly possible to make an init implementation that uses
Linux-only technologies on Linux, but which falls back to a different
mode on non-Linux. The reasl reason why systemd is Linux-only is because
systemd upstream decided it would be easier to implement systemd that
way, and because they didn't care about non-Linux. I find that to be
lazyness; but that is, of course, their prerogative.

At any rate, I think the only solution to the dilemma here would seem to
be if someone were to port systemd to kFreeBSD. If neither the kFreeBSD
people nor the systemd people are willing to work on that, then we can
discuss and talk about this into eternity, but it will be highly
unlikely that we'll ever arrive at a solution.

kFreeBSD is already part of Debian. Systemd is not. The answer would
seem to be obvious.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a


-- 
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/20120306152356.ge15...@grep.be

Re: upstart: please update to latest upstream version

[Ben Hutchings]

On Tue, Mar 06, 2012 at 08:07:37AM +0100, Wouter Verhelst wrote:
> On Mon, Mar 05, 2012 at 02:44:45PM +0100, Marco d'Itri wrote:
> > On Mar 05, Marc Haber  wrote:
> > 
> > > Should Debian restrict itself to being a Linux platform just to have
> > > systemd?
> > If it is worth it, yes.
> > 
> > Should Debian reject using  > component> just to support toy ports which are used by a dozen of people?
> 
> Except that kFreeBSD is not a toy port.
> 
> FreeBSD is a serious operating system that is used by many people in
> system-critical applications, which runs on modern hardware and
> outperforms the hell of Linux in some regards.

It is Debian GNU/kFreeBSD being called a toy and not the FreeBSD
operating system.

> The kFreeBSD port has some features over Linux that makes it an
> interesting option for some use cases, such as ZFS, jails, and more.
[...]

ZFS is interesting, yes.  Linux device-mapper provides many of the
features but I recognise there can be a benefit from integrating these
into the filesystem iself.  Any year now, btrfs may be mature enough
to use...

Do jails still provide features that LXC does not?

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


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

Bug#662819: ITP: libstring-similarity-perl -- Perl module for calculating the similarity of two strings

[Fabrizio Regalli]

Package: wnpp
Owner: Fabrizio Regalli 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libstring-similarity-perl 
  Version : 1.04
  Upstream Author : Marc Lehmann 
* URL : http://search.cpan.org/dist/String-Similarity
* License : GPL-2+
  Programming Lang: Perl
  Description : Perl module for calculating the similarity of two strings

 String::Similarity calculates the similarity index of its two arguments.
 A value of 0 means that the strings are entirely different. A value
 of 1 means that the strings are identical. Everything else lies between 
 0 and 1 and describes the amount of similarity between the strings.



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

Re: upstart: please update to latest upstream version

[Adam Borowski]

On Tue, Mar 06, 2012 at 03:58:49PM +, Ben Hutchings wrote:
> Do jails still provide features that LXC does not?

Like, say, any security separation at all?

LXC is a glorified chroot with some scheduler niceties and a way to set
default IP for a group of processes.  If you want any security benefits,
you need vserver, openvz or BSD jails.


Speaking of which, did any of you guys start some work to get vserver or
openvz packaged the Debian way, as discussed in the recent flamewar?  Having
to use the upstream kernel patch directly is a massive duplication of work.

-- 
// 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: upstart: please update to latest upstream version

[Tollef Fog Heen]

]] Wouter Verhelst 

> kFreeBSD is already part of Debian. Systemd is not. The answer would
> seem to be obvious.

$ rmadison systemd
 systemd | 37-1| wheezy | source, amd64, armel, i386, ia64, mips, mipsel, 
powerpc, s390, s390x, sparc
 systemd | 37-1+b1 | wheezy | armhf
 systemd | 37-1.1  | sid| source, amd64, armel, armhf, i386, ia64, mips, 
mipsel, powerpc, s390, s390x, sparc

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


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

Bug#662840: ITP: wims-java-applets -- applets for modules used by the WIMS server

[Georges Khaznadar]

Package: wnpp
Severity: wishlist
Owner: Georges Khaznadar 

* Package name: wims-java-applets
  Version : 2012.03.05+svn5129
  Upstream Author : oke Evers 
* URL : http://www.wimsedu.info
* License : Public Domain
  Programming Lang: Java
  Description : applets for modules used by the WIMS server
 This package was formerly made from the source package for wims.
 However, wims cannot be built completely on architectures which have
 no JVM available, so it could not enter testing. Hence the separation of the
 source packages.
 .
 Wims recommends wims-java-applets.
 .
 Wims' modules implement every user interface beyond its main page,
 the non exhaustive list of the features is: administrative tasks, help,
 and a few interactive exercises, mathematic tools, libraries ...
 .
 This package does not contain the thousands of exercices which are
 partly provided by the optional package wims-extra.
 .
 Other educational contents can be downloaded outside of the Debian
 system by automated updates. See http://www.wimsedu.info



-- 
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/20120306184303.13580.27873.report...@georges.khaznadar.fr

Bug#662849: ITP: bwctl -- bandwidth test controller

[Raoul Gunnar Borenius]

Package: wnpp
Severity: wishlist
Owner: Raoul Gunnar Borenius 

* Package name: bwctl
  Version : 1.3
  Upstream Author : Jeff Boote , Aaron Brown 

* URL : http://www.internet2.edu/performance/bwctl/
* License : custom license (but upstream is thinking
about changing to a well known license):

/*
*
* Redistribution and use in source and binary forms, with or without 
modification,
* are permitted provided that the following conditions are met:
* 
* * Redistributions of source code must retain the following copyright 
notice,
*   this list of conditions and the disclaimer below.
* 
*Copyright (c) 2003-2008, Internet2
* 
*  All rights reserved.
* 
* * Redistribution in binary form must reproduce the above copyright notice,
*   this list of conditions and the following disclaimer in the 
documentation
*   and/or other materials provided with the distribution.
* 
**  Neither the name of Internet2 nor the names of its contributors may be
*   used to endorse or promote products derived from this software without
*   explicit prior written permission.
* 
* You are under no obligation whatsoever to provide any enhancements to 
Internet2,
* or its contributors.  If you choose to provide your enhancements, or if you
* choose to otherwise publish or distribute your enhancement, in source code 
form
* without contemporaneously requiring end users to enter into a separate written
* license agreement for such enhancements, then you thereby grant Internet2, its
* contributors, and its members a non-exclusive, royalty-free, perpetual license
* to copy, display, install, use, modify, prepare derivative works, incorporate
* into the software or other computer software, distribute, and sublicense your
* enhancements or derivative works thereof, in binary and source code form.
* 
* DISCLAIMER - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
CONTRIBUTORS
* “AS IS” AND WITH ALL FAULTS.  THE UNIVERSITY OF DELAWARE, INTERNET2, ITS 
CONTRI-
* BUTORS, AND ITS MEMBERS DO NOT IN ANY WAY WARRANT, GUARANTEE, OR ASSUME ANY 
RES-
* PONSIBILITY, LIABILITY OR OTHER UNDERTAKING WITH RESPECT TO THE SOFTWARE. ANY 
E-
* XPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED 
WARRAN-
* TIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND 
NON-INFRINGEMENT
* ARE HEREBY DISCLAIMED AND THE ENTIRE RISK OF SATISFACTORY QUALITY, 
PERFORMANCE,
* ACCURACY, AND EFFORT IS WITH THE USER THEREOF.  IN NO EVENT SHALL THE 
COPYRIGHT
* OWNER, CONTRIBUTORS, OR THE UNIVERSITY CORPORATION FOR ADVANCED INTERNET 
DEVELO-
* PMENT, INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, 
EXEMPLARY,
* OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
SUBSTIT-
* UTE GOODS OR SERVICES; REMOVAL OR REINSTALLATION LOSS OF USE, DATA, SAVINGS OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF 
LIABILIT-
* Y, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR 
OTHE-
* RWISE) ARISING IN ANY WAY OUT OF THE USE OR DISTRUBUTION OF THIS SOFTWARE, 
EVEN
* IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
* 
**/

  Programming Lang: C
  Description : bandwidth test controller

BWCTL is a command line client application and a scheduling and policy daemon
that wraps the throughput testing tools Iperf, Thrulay, and Nuttcp.
These tests can measure maximum TCP bandwidth, with various tuning options
available, or, by doing a UDP test, the delay, jitter, and datagram loss
of a network.



--
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/20120306193404.6794.24885.report...@sid-amd64.sgs.dfn.de

libidn re-license

[Simon Josefsson]

I co-maintain the libidn package.  As upstream, I recently relicensed it
from LGPLv2+ to GPLv2+|LGPLv3+.  I'd like to upload the latest version
into Debian before Wheezy since a pretty nasty inifinte-loop bug has
been fixed.  However, I am not certain what should be done before
uploading a re-licensed package, so I am asking for guidance.  I have
looked at licenses of reverse dependencies, and I did found some
GPLv2-only packages.  That caused me to dual license the package instead
of going to LGPLv3+. (GPLv2-only and LGPLv3+ are incompatible.)  I am
not aware of any other license that could pose any problem with a
dual-licensed GPLv2+|LGPLv3+ package.  I didn't find any other obvious
problem when I looked at the reverse dependencies.

Is there any policy or best current practice about what needs to be done
in this situation?  Should I just upload to unstable and let people work
out license (in)compatibility later on?  I'm sure this must have come up
before for other packages that have been relicensed, but I couldn't find
any generic advice.

/Simon


-- 
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/87hay1r086@latte.josefsson.org

Re: debian-multimedia.org considered harmful, Was: Unofficial repositories on 'debian' domains

[Christoph Anton Mitterer]

Hey.

Stupid question... but even for those packages, which Debian provides
now itself (by the fine work of the pkg-multimedia-maintainers)... are
they build with all the options enabled?

I believe to remember that there were some cases where mp4 stuff was
disabled then...


I surely haven't had to work as closely with Christian as you guys
did,.. but I sometimes notified him of packages which used to show up in
Debian (libaacs and friends) and he dropped them from DMO.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#662876: ITP: libhtml-formattext-withlinks-andtables-perl -- Converts HTML to Text with tables in tact

[Fabrizio Regalli]

Package: wnpp
Owner: Fabrizio Regalli 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libhtml-formattext-withlinks-andtables-perl
  Version : 0.01
  Upstream Author : Shaun Fryer 
* URL : 
http://search.cpan.org/dist/HTML-FormatText-WithLinks-AndTables/
* License : unparsable
  Programming Lang: Perl
  Description : Converts HTML to Text with tables in tact

HTML::FormatText::WithLinks::AndTables was inspired by
HTML::FormatText::WithLinks which has proven to be a useful `lynx -dump`
work-alike. However one frustration was that no other HTML converters I came
across had the ability to deal affectively with HTML s. This module
can in a rudimentary sense do so. The aim was to provide facility to take a
simple HTML based email template, and to also convert it to text with the
 structure in tact for inclusion as "multipart/alternative" content.
Further, it will preserve both the formatting specified by the  tag's
"align" attribute, and will also preserve multiline text inside of a 
element provided it is broken using  tags.



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

Re: upstart: please update to latest upstream version

[Josh Triplett]

Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 02:08:00PM +, Jon Dowland wrote:
> > On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > > But I do think that writing portable software isn't that hard, and that 
> > > not
> > > doing it is pure lazyness.
> > 
> > It's not about difficulty, systemd isn't not-portable simply because the
> > authors haven't got around to it yet; it fundamentally relies on a 
> > Linux-only
> > technology.
> 
> This is wrong. An init implementation is not fundamentally Linux-only.
> No matter how they chose to implement it, no matter what they've ended
> up with, it is fundamentally possible to write an init implementation
> that will work on more than just Linux.

You've said something entirely different here that doesn't refute the
point you replied to.  systemd fundamentally relies on Linux-only
technologies, because it specifically provides access to those
technologies, takes full advantage of those technologies, and uses them
to provide an init system capable of doing things that sysvinit can't
do.  What you said remains true: you *can* write an init implementation
that will work on more than just Linux, and sysvinit provides an
existence proof backing up your claim; that doesn't mean you can write
systemd or an init implementation with equivalent functionality, just
that you can write a least-common-denominator init system as capable as
sysvinit.  This thread exists in large part because many people want an
init system more capable than sysvinit.

To give one particular example: systemd uses Linux-specific features to
accurately track all the processes started by a service, which allows
accurate monitoring and shutdown of processes which could otherwise
disassociate themselves from their parent processes via the usual
daemonizing trick.  POSIX doesn't provide features that allow this in
general, but Linux does.  (Quite possibly other OSes provide those
features too, but not in a standardized way.)

> It is perfectly possible to make an init implementation that uses
> Linux-only technologies on Linux, but which falls back to a different
> mode on non-Linux. The reasl reason why systemd is Linux-only is because
> systemd upstream decided it would be easier to implement systemd that
> way, and because they didn't care about non-Linux. I find that to be
> lazyness; but that is, of course, their prerogative.

You've got your cause and effect backward here.  systemd specifically
provides access to Linux-only features to provide functionality it
couldn't otherwise provide.  *Given* that systemd already needs
Linux-specific functionality, upstream figured that they might as well
continue using other Linux-specific functionality that makes things
easier, rather than writing everything to the lowest common denominator
of what a pile of OSes support.

> At any rate, I think the only solution to the dilemma here would seem to
> be if someone were to port systemd to kFreeBSD. If neither the kFreeBSD
> people nor the systemd people are willing to work on that, then we can
> discuss and talk about this into eternity, but it will be highly
> unlikely that we'll ever arrive at a solution.

You've missed several other possibilities here:

- kFreeBSD implements a systemd-compatible init system that doesn't
  necessarily represent a port of all of the systemd codebase.  I
  suspect that systemd wouldn't object to making a few library bits
  portable, such as code parsing systemd service files, to allow sharing
  that between implementations.

- kFreeBSD implements kernel APIs compatible with the Linux APIs that
  systemd requires, drastically reducing the amount of porting work
  required, and turning it into a configuration problem.  That would
  benefit many more pieces of software, not just systemd.  Note that
  kFreeBSD has a huge headstart here, because it already uses glibc, and
  thus doesn't need to worry about all the glibc-specific APIs.  One of
  systemd's major development tenets roughly amounts to "fix bugs, don't
  work around them, even when those bugs live in the kernel (because we
  can fix that too)"; that tenet represents a large part of systemd's
  non-portability.

- systemd continues to become more popular, and upstreams start
  depending on it inherently and using systemd features that make it
  non-trivial to write a simplistic init script with equivalent
  functionality.  Debian eventually finds the rug pulled out from under
  it.  See udev for a successful application of this strategy, with
  exactly the same rationale: static /dev doesn't give you the
  capabilities required to implement interesting functionality, such as
  hotplug and event-driven device handling.  Net result: Debian ends up
  in the same place, but after inflicting sysvinit on people for much
  longer.

> kFreeBSD is already part of Debian. Systemd is not. The answer would
> seem to be obvious.

"First come, first served" does not inherently represent a sensible
problem-sol

Re: upstart: please update to latest upstream version

[Fernando Lemos]

Hi,

On Tue, Mar 6, 2012 at 7:46 PM, Josh Triplett  wrote:
> To give one particular example: systemd uses Linux-specific features to
> accurately track all the processes started by a service, which allows
> accurate monitoring and shutdown of processes which could otherwise
> disassociate themselves from their parent processes via the usual
> daemonizing trick.  POSIX doesn't provide features that allow this in
> general, but Linux does.  (Quite possibly other OSes provide those
> features too, but not in a standardized way.)

By the way, upstart uses ptrace for this:

http://netsplit.com/2007/12/07/how-to-and-why-supervise-forking-processes/

It's an interesting trick, and probably more portable too.

Regards,


--
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/canvyna-nyq9y1ayxdpbsnwwwa15o3y1rcov++_zh6wct9gf...@mail.gmail.com

Re: libidn re-license

[Paul Wise]

I would suggest asking the FSF licensing folks and debian-legal.

-- 
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/CAKTje6HD9YoJaMAk=tqm3c7tc9oq+kxf0vu9dxvjtkxrcr5...@mail.gmail.com

Re: Unofficial repositories on 'debian' domains

[Karl Goetz]

On Mon, 5 Mar 2012 22:19:09 +0100
Stefano Zacchiroli  wrote:

> On Mon, Mar 05, 2012 at 08:09:47PM +, Philipp Kern wrote:
> > The reason being what?  We have ZIP password crackers in the
> > archive, too.
> 
> Cracking ZIP passwords doesn't fall under the auspices of DMCA or your
> equivalent $county_specific_law (and there are quite a few around the
> world, unfortunately).

I'm surprised, I thought DMCA applied to circumventing protections
designed to 'protect' copyright.
thanks,
kk

-- 
Karl Goetz, (Kamping_Kaiser / VK7FOSS)
http://www.kgoetz.id.au
No, I won't join your social networking group
*** I've changed GPG key to 6C097260 ***


signature.asc
Description: PGP signature

Re: upstart: please update to latest upstream version

[Steve Langasek]

On Wed, Feb 29, 2012 at 09:54:56AM +0100, Goswin von Brederlow wrote:

> >> One of the worst contributors to the use of 'script' in upstart jobs
> >> instead of 'exec' is the need for backwards-compatibility with pre-upstart
> >> /etc/default/* files.  The options here are all fairly poor:

> >>  - ignore the admin's /etc/default settings when switching init systems
> >>  - migrate any local changes to /etc/default into the upstart job at
> >>upgrade time, by editing a conffile in a maintainer script
> >>  - keep sourcing /etc/default at runtime

> >> I guess systemd has largely chosen option 1 (in part because there's a
> >> weird view in the systemd community that these jobs belong upstream, so
> >> Debian integration issues are entirely ignored).  For many upstart jobs in
> >> Ubuntu, we've chosen option 3.  Which do you think is the right solution?
> >> Are there other options I haven't seen?

> > Of those listed above, I'd agree with option 3 or some optimisation of it 
> > –
> > option 2, modified to do the migration at runtime if /etc /default/foo has
> > been modified since last seen, would cover that, I think.

> Do upstart jobs have an include directive?

They support a .override file alongside the .conf, which could be used to
export additional variables to the environment.  That's probably the closest
functional equivalent to an include here, and works without any extra I/O
overhead for additional files, or extra CPU overhead from spawning shells,
in the default case.

Thanks, I hadn't really thought of that before.  I think I may play around
with an /etc/default -> .override on package upgrade, to see how it fares.

(Of course, this does mean that the upstart job and init script would be
*looking at two different* files for their admin-modified configuration, so
that's not an ideal solution for ongoing maintainability in Debian; but it
sounds to me like it's better than nothing.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: Enabling hardened build flags for Wheezy

[Charles Plessy]

Le Wed, Feb 29, 2012 at 10:52:10PM +0100, Moritz Muehlenhoff a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> 
> Since it will be almost impossible to convert all packages before
> Wheezy freezes, a specific sub-group of packages receives targeted 
> attention:
> 
> * All packages, which have had a DSA since 2006
> * All packages, which are of Priority >= important

Dear Moritz and everybody,

we are starting to receive bugs, severity important, for packages that are not
of the above, where for instance the patch consists in bumping Debhelper's
compatibility level from 8 to 9.

I admit that I have strictly no understanding of the consequences of not fixing
these bugs in a timely manner.  Severity important suggests to me that it is
better to solve that bug first before doing other works such as introducing new
features or updating other packages, and that there is an "important" risk for
our users of being victims of attacks that can be prevented by the hardening.
Perhaps people could file these bugs at a "normal" severity, if this is not the
case.

But my main question is the following:

In another bug, the problem is that CPPFLAGS is ignored in upstream's makefile.
I understand that the semantics of CFLAGS and CPPFLAGS are not the same, but I
also note that a large number of our upstreams are not making the difference
and use CFLAGS as a catch-all varible.

Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in addition to
CPPFLAGS ?

Have a nice day,

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


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

Re: Enabling hardened build flags for Wheezy

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Charles,

On 07.03.2012 00:58, Charles Plessy wrote:
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in 
> addition to CPPFLAGS ?

Actually dpkg did in 1.16.1 which was reverted later (for good
reasons). See #643632 for details.

You can easily inject CPPFLAGS into CFLAGS if your upstream Makefile
does cope with CFLAGS only by doing something like:

CFLAGS := $(shell dpkg-buildflags --get CFLAGS) $(shell
dpkg-buildflags --get CPPLAGS)
LDFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
export CFLAGS LDFLAGS

n.b. you need a build dependency against dpkg-dev >= 1.16.1 doing so.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPVqZeAAoJEMcrUe6dgPNtdqIP/3trPYFCuTbUx2rLW5x/99UL
rdxozFS3gKApy7rm8tILIhuCB58hJ1GcVaoiFcD7WAsGYS8iTwD9vdmcMPHtpKK+
36iRfpWao8r06O8kuuXGGchPmUudeASSkh67yIDwsazli21WZxNxaVl0VRQhvsFW
SVTdSPEwXQdfJrjvngSQItfqOBEUoV3OYI+pTk0LW58lfEHlPE6WkCZrc7SipQQ4
dx2KPnnEHEJRfexZ6/J56YtDkg/wxze2vAamwlbbY88zctv1O9h5HPsZbMovfS79
fcxAbsHn/4xkruRmlPhcCFIu3cSh5bk6Cp5NsL2o6HPmSfdhBWxxsyu2oUiNeDQa
DKV750cdNHJwK5tMDupbssJrOBqqk0RkKZDzkk/RYP/ncXlHPMGZYjx5ESLGuUt4
seNkdq+dT3PGrZ1F1ziLB2TKWAZ7Uldjc6t1LI4xOC+hG/vdi4s9nEZCaJ41YfTA
EiI7CZWKq+aC2FW2dcPZLIbKCsV2cYP2UkQFcVLWUQtbJB3WXTTLRcX+nc9brfhp
xOZp+f8vcqif8XqcNxvwgyKc97tNWjnwYMdtFaQ6MpgYCmnECJtUkSeenPsgkCJh
D1p1adDivyq1CCegz4ONIux94wIC8e75ZdX0eAacm3tmErPMP3mF2NpdtSeuuVp1
9O9t+6PruQQZNDsnJvYL
=Xeea
-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/4f56a65e.5040...@toell.net

Re: Enabling hardened build flags for Wheezy

[Cyril Brulebois]

Charles Plessy  (07/03/2012):
> But my main question is the following:
> 
> In another bug, the problem is that CPPFLAGS is ignored in upstream's
> makefile.  I understand that the semantics of CFLAGS and CPPFLAGS are
> not the same, but I also note that a large number of our upstreams are
> not making the difference and use CFLAGS as a catch-all varible.
> 
> Would it be possible to pass -D_FORTIFY_SOURCE=2 in CFLAGS in addition
> to CPPFLAGS ?

I guess you could do something like (for C and C++ respectively for sane
upstreams, you might not need the CXX part given what you wrote):
  # do the dpkg-buildflags dance to get everything exported
  CFLAGS   += $(CPPFLAGS)
  CXXFLAGS += $(CPPFLAGS)

so that the CPPFLAGS aren't lost?

Of course, you could avoid exporting everything to retain control over
what's exported to the rest of the build process, in which case you
could do something along those lines:
  CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
  CFLAGS   = $(shell dpkg-buildflags --get CFLAGS  ) $(CPPFLAGS)
  CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS) $(CPPFLAGS)
  LDFLAGS  = $(shell dpkg-buildflags --get LDFLAGS )

then pass those variables explicitly to ./configure:
  dh_auto_configure -- ... CFLAGS="$(CFLAGS)" CXXFLAGS="$(CXXFLAGS)" 
LDFLAGS="$(LDFLAGS)"

There are probably other ways to do this in compat 9, but I didn't
investigate it yet.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: upstart: please update to latest upstream version

[Peter Samuelson]

[Josh Triplett]
> To give one particular example: systemd uses Linux-specific features
> to accurately track all the processes started by a service, which
> allows accurate monitoring and shutdown of processes which could
> otherwise disassociate themselves from their parent processes via the
> usual daemonizing trick.

This "one particular example" is the same feature (cgroups) that
everyone keeps talking and talking about.  Everyone keeps saying
"systemd uses Linuxisms like cgroups", but nobody mentions any others.
Is this the only major Linuxism in systemd, or is it just the only one
that's interesting enough to talk about?

I ask because, if porting systemd to kFBSD is a mere matter of
emulating cgroups with jails (from what I understand, jails provide
roughly a superset of cgroups functionality), that's a somewhat
different picture than I've been assuming.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: upstart: please update to latest upstream version

[Cyril Brulebois]

Peter Samuelson  (06/03/2012):
> This "one particular example" is the same feature (cgroups) that
> everyone keeps talking and talking about.  Everyone keeps saying
> "systemd uses Linuxisms like cgroups", but nobody mentions any others.
> Is this the only major Linuxism in systemd, or is it just the only one
> that's interesting enough to talk about?

Some hints:
  http://archive.fosdem.org/2011/interview/lennart-poettering

see “Which Linux-specific functionality […]”.

This might help too:
  
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart

As for upstart, the following bits were mentioned a while ago:
  http://lists.debian.org/debian-bsd/2009/07/msg00122.html

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Unofficial repositories on 'debian' domains

[Ben Hutchings]

On Wed, 2012-03-07 at 10:35 +1100, Karl Goetz wrote:
> On Mon, 5 Mar 2012 22:19:09 +0100
> Stefano Zacchiroli  wrote:
> 
> > On Mon, Mar 05, 2012 at 08:09:47PM +, Philipp Kern wrote:
> > > The reason being what?  We have ZIP password crackers in the
> > > archive, too.
> > 
> > Cracking ZIP passwords doesn't fall under the auspices of DMCA or your
> > equivalent $county_specific_law (and there are quite a few around the
> > world, unfortunately).
> 
> I'm surprised, I thought DMCA applied to circumventing protections
> designed to 'protect' copyright.

The DVD-CCA requires that licenced DVD players hide decryption keys and
the decrypted bitstream from the user, and that they restrict playback
in various ways.  Unlicenced players might not have such restrictions,
but will also not be given player keys.  So CSS 'effectively controls
access to the work' on DVDs that use it, and circumvention is against
the law in the USA (and many other countries).

Whereas, with zip encryption, the intended recipient must be given the
password, and the unzip program will then provide them with the
decrypted files to use and copy as they wish.  So this is not copy
protection or access control, and password cracking therefore does not
seem to be forbidden by those laws.  (But there may be other laws not
related to copyright that do forbid such tools.)

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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

Re: MIA check for Robert Jordens and Mark A. Hershberger (anyone in contact with them?)

[Robert Jordens]

I have resigned from Debian a while ago.

-- 
Robert Jordens.


-- 
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/CANb+zoHpJYZw4qhP-XpxzOJKid3uLe_=t1p4gfzcf4vnvyd...@mail.gmail.com

Re: A few observations about systemd

[Marc Haber]

On Tue, 6 Mar 2012 10:01:10 +, Jon Dowland 
wrote:
>Are we asking different standards from systemd
>than we expect from core openssh?

The differences between systemd and openssh are that core OpenSSH does
not work on "our" main architecture, and that there is an active
non-Debian upstream for Portable OpenSSH. If there were something like
"portable systemd", I guess that the voices against systemd would be a
lot quieter here.

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1s5ab9-0002jc...@swivel.zugschlus.de

Re: libidn re-license

[Florian Weimer]

* Simon Josefsson:

> I co-maintain the libidn package.  As upstream, I recently relicensed it
> from LGPLv2+ to GPLv2+|LGPLv3+.  I'd like to upload the latest version
> into Debian before Wheezy since a pretty nasty inifinte-loop bug has
> been fixed.

Should we get that into stable-security, under the old license?

> I have looked at licenses of reverse dependencies, and I did found
> some GPLv2-only packages.  That caused me to dual license the
> package instead of going to LGPLv3+.

This is appreciated.

> (GPLv2-only and LGPLv3+ are incompatible.)

Nowadays, almost all GPLv2-only programs link to library code licensed
under the GPLv3 (with a linking exception on the library side), so we
pretend that they are, at least to some degree.


-- 
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/87d38og8qf@mid.deneb.enyo.de