Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Andrei POPESCU
On Vi, 28 mar 14, 17:39:39, Paul Wise wrote:
> On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:
> 
> > Alternatively, we could make NetworkManager the default.
> > It is already here, it works, and it doesn’t have such problems.
> 
> Or systemd-networkd.

Or connman.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature


Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)

2014-03-28 Thread Olav Vitters
On Fri, Mar 28, 2014 at 11:08:54AM -0500, Kevin Toppins wrote:
> On 28 Mar 2014 03:40, Olav Vitters wrote:
> [...]
> > > I can tell you right now, it is *vastly more difficult* to try to
> > > adapt programs modified to work with systemd in their current state,
> > > than it is to *revert* those programs to their pre-systemd state.
> >
> > You're so certain while so utterly wrong on so many levels it is pretty
> > amusing and embarrassing at the same time. You said you don't easily get
> > offended, but hopefully you do pickup some learnings here.
> 
> 
> Did you understand that...
> 
> There are (at least) two paths to take here, and this is referring to
> the more difficult of the two.  The easier choice is the reversion
> then selective upgrade path.

Nope.

> I did go on to explain why the first path was more difficult.  Did you
> consider what I said there?

You claimed, you never explained.

Ryan analysed, convinced maintainers, convinced other developers,
convinced release team.

There is a *huge* difference between the two.

> Please, put why I'm so utterly wrong into writing here and let's see
> what you understand.

That is pointless; I don't care what you wanted to prove. Do the same
amount of work others have done for starters, then we'll see.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140329020452.gb17...@bkor.dhs.org



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Matt Grant
Hi!

Actually, I would love to cleanly modify ifupdown with a lot of the
experience I have gained from netscript, and working on actual routers.
Making it not so onerous would not be that much work, and it would have
far better behaviour once improvements are made.

I am putting myself forward for this as with the systemd update
netscript-2.4 needs to be 'bodged' in a bit to make it work.  I will do
this, but getting ifupdown with a better operational method and feature
set will make it far easier to use for the server case as well.

Cheers,

Matt Grant

On Fri, 2014-03-28 at 15:08 -0700, Russ Allbery wrote:
> Josselin Mouette  writes:
> > Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit :
> 
> >> I realize that doing that well is not horribly challenging, but that is
> >> the most common server use case (and even desktop), and ifupdown does
> >> it quite well.
> 
> > Come on. We all use ifupdown on our servers just because it is the
> > default and works well enough. Bringing up a pair of static IPs and a
> > bonding link is not very challenging. But we shouldn’t judge a network
> > management tool based on how to achieve the simplest task: any tool will
> > do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its
> > horrible design and antique syntax, works well enough for most of its
> > users.
> 
> > And in the desktop case, I disagree that ifupdown does the job. User
> > applications want to be notified of the network’s status, and it
> > requires more than what ifupdown can offer.
> 
> That sounds like vehement agreement with what I just said.  :)
> 
> Having used both, ifupdown, despite its problems, is certainly better than
> the Red Hat approach in /etc/sysconfig.
> 
> >> I don't want to lose that, and I don't want to add a bunch of
> >> complexity in order to satisfy that case.  I think there will always be
> >> a place for a very *simple* system to handle that case with some pre
> >> and post hooks for things like iptables rule installation.
> 
> > This is one of the possible scopes of systemd-networkd. But I think it
> > is being designed more for cases like the initramfs, where you cannot
> > have a full-blown networking management tool like NM.
> 
> It's quite possible that systemd-networkd will eventually become a good
> tool to do this.  It just isn't now.  Now would be a wonderful time for
> people who care to get involved, if they feel like that would be a good
> long-term solution, since it would be much easier to design a conversion
> path from existing ifupdown systems at this early stage in the project.
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 
> 



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1396044965.17962.5.ca...@moriah.internal.anathoth.net



Re: FTPMaster position statement about package contents

2014-03-28 Thread Joerg Jaspert
On 13529 March 1977, Steve Langasek wrote:

> I can understand the ftp team's desire to sidestep any moral questions here,
> but in the process I think your guidelines have wound up vague and
> overbroad, as they suggest that as a project we will never take a stand for
> anything but only do what's safe.

Yes, they are vague. We are using the most extreme example, but besides
that we haven't listed anything specific.

Now, your question does imply that the FTP Team should take over the
moral judgement for the project. Should we issue statements that
$somesubject is unacceptable for Debian as a project, instead of "just"
for the archive, the area we are responsible for?

I reply to the rest later.

-- 
bye, Joerg
Die Dicke zum Spiegel: Spieglein, Spieglein an der Wand, wer ist die
Schönste im ganzen Land?
Der Spiegel: Geh doch mal weg, ich kann ja gar nichts sehen!


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ob0qugas@gkar.ganneff.de



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Russ Allbery
Josselin Mouette  writes:
> Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit :

>> I realize that doing that well is not horribly challenging, but that is
>> the most common server use case (and even desktop), and ifupdown does
>> it quite well.

> Come on. We all use ifupdown on our servers just because it is the
> default and works well enough. Bringing up a pair of static IPs and a
> bonding link is not very challenging. But we shouldn’t judge a network
> management tool based on how to achieve the simplest task: any tool will
> do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its
> horrible design and antique syntax, works well enough for most of its
> users.

> And in the desktop case, I disagree that ifupdown does the job. User
> applications want to be notified of the network’s status, and it
> requires more than what ifupdown can offer.

That sounds like vehement agreement with what I just said.  :)

Having used both, ifupdown, despite its problems, is certainly better than
the Red Hat approach in /etc/sysconfig.

>> I don't want to lose that, and I don't want to add a bunch of
>> complexity in order to satisfy that case.  I think there will always be
>> a place for a very *simple* system to handle that case with some pre
>> and post hooks for things like iptables rule installation.

> This is one of the possible scopes of systemd-networkd. But I think it
> is being designed more for cases like the initramfs, where you cannot
> have a full-blown networking management tool like NM.

It's quite possible that systemd-networkd will eventually become a good
tool to do this.  It just isn't now.  Now would be a wonderful time for
people who care to get involved, if they feel like that would be a good
long-term solution, since it would be much easier to design a conversion
path from existing ifupdown systems at this early stage in the project.

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


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



Bug#742911: ITP: python-cryptography-vectors -- Test vectors for python-cryptography

2014-03-28 Thread Tristan Seligmann
Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name: python-cryptography-vectors
  Version : 0.3
  Upstream Author : Cryptography developers
* URL : https://cryptography.io/
* License : Various
  Programming Lang: None
  Description : Test vectors for python-cryptography

Upstream has split the test vectors out from the main cryptography
package, due to their size.

I still need to do the work of tracking down all of the
copyright/licensing information, as the test vectors are almost all
drawn from external sources (IETF / NIST / etc.). This should have been
done for the python-cryptography 0.2 upload which included the test
vectors, but unfortunately I overlooked this issue.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140328213113.30999.5721.report...@lorien.mithrandi.net



Re: FTPMaster position statement about package contents

2014-03-28 Thread Steve Langasek
On Fri, Mar 28, 2014 at 09:49:44PM +0100, Bas Wijnen wrote:
> On Thu, Mar 27, 2014 at 07:41:50PM -0700, Steve Langasek wrote:
> > I can understand the ftp team's desire to sidestep any moral questions here,
> > but in the process I think your guidelines have wound up vague and
> > overbroad, as they suggest that as a project we will never take a stand for
> > anything but only do what's safe.

> I think you are mistaken.  The statement says that before uploading, we
> should ask the ftp team for advice.  Not that they will always deny the
> upload.

> What it means, is that they don't want rigid rules where there are
> problems when we get a new member from a new country, but instead leave
> the decision to humans (the ftp team).  I think that is very wise.

If your interpretation is correct, then the mail from Joerg in practice
provides *no* new guidance, and the only reason the software in question is
blocked from the archive is "because the ftp team says so".

That's an even worse policy than how I interpreted it.

-- 
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: FTPMaster position statement about package contents

2014-03-28 Thread Bas Wijnen
Hi,

On Thu, Mar 27, 2014 at 07:41:50PM -0700, Steve Langasek wrote:
> I can understand the ftp team's desire to sidestep any moral questions here,
> but in the process I think your guidelines have wound up vague and
> overbroad, as they suggest that as a project we will never take a stand for
> anything but only do what's safe.

I think you are mistaken.  The statement says that before uploading, we
should ask the ftp team for advice.  Not that they will always deny the
upload.

What it means, is that they don't want rigid rules where there are
problems when we get a new member from a new country, but instead leave
the decision to humans (the ftp team).  I think that is very wise.

> For another example, software patents are not valid in the EU, but they are
> valid in many countries outside the EU.  We have a policy that software
> known to infringe patents should not be included in the archive, but your
> latest mail expresses a much broader policy: that developers shouldn't even
> upload software that *maybe* is illegal in the majority of countries of our
> developers.  If you asked me if a particular package infringed software
> patents in most countries, I would always have to answer "maybe".  So does
> this mean we should all stop uploading all software?

I'd suggest we use subjective human judgement when we decide whether or
not to contact the ftp team as well. ;-)

Thanks,
Bas


signature.asc
Description: Digital signature


Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Josselin Mouette
Le vendredi 28 mars 2014 à 11:55 -0700, Russ Allbery a écrit :
> I realize that doing that well is not horribly challenging, but that is
> the most common server use case (and even desktop), and ifupdown does it
> quite well.

Come on. We all use ifupdown on our servers just because it is the
default and works well enough. Bringing up a pair of static IPs and a
bonding link is not very challenging. But we shouldn’t judge a network
management tool based on how to achieve the simplest task: any tool will
do that. Even Red Hat’s /etc/sysconfig/network-scripts, despite its
horrible design and antique syntax, works well enough for most of its
users.

And in the desktop case, I disagree that ifupdown does the job. User
applications want to be notified of the network’s status, and it
requires more than what ifupdown can offer.

> I don't want to lose that, and I don't want to add a bunch of
> complexity in order to satisfy that case.  I think there will always be a
> place for a very *simple* system to handle that case with some pre and
> post hooks for things like iptables rule installation.

This is one of the possible scopes of systemd-networkd. But I think it
is being designed more for cases like the initramfs, where you cannot
have a full-blown networking management tool like NM.

-- 
.''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1396039687.4331.41.ca...@kagura.malsain.org



Re: systemd patent fees - who pays?

2014-03-28 Thread Ben Hutchings
On Fri, 2014-03-28 at 11:40 +0100, Sebastian Feld wrote:
> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:
> 
> SystemD violates a couple of patents SUN Microsystems filed for their
> SMF system used in Solaris.
> 
> Now, who is going to pay the patent and license fees for each Debian
> installation which uses SystemD?

When is Oracle going to kill OEL?

Because if there is an OEL 7, and it's still a clone of RHEL, Oracle
will have to licence those patents to everyone without fee.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.


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


Bug#742899: ITP: cppad -- Automatic Differentiation (AD) of C++ algorithms

2014-03-28 Thread Miles Lubin
Package: wnpp
Severity: wishlist
Owner: Miles Lubin 

* Package name: cppad
  Version : 20140301
  Upstream Author : Bradley M. Bell 
* URL : https://projects.coin-or.org/CppAD/
* License : GPL-3 and EPL (dual licensed)
  Programming Lang: C++
  Description : Automatic Differentiation (AD) of C++ algorithms

Given a C++ algorithm that computes function values, CppAD generates an
algorithm that computes its exact derivative values.

CppAD is used in a number of scientific computing applications to automate the
computation of exact derivatives of codes implemented in C++. It is a pure
header library with no binaries. CppAD is similar in concept to the adolc
package already in Debian. I intend to co-maintain with Barak Pearlmutter under
Debian Science.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140328190631.10311.64357.report...@debian.mit.edu



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Russ Allbery
Paul Wise  writes:
> On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:

>> Alternatively, we could make NetworkManager the default.
>> It is already here, it works, and it doesn’t have such problems.

> Or systemd-networkd.

systemd-networkd is not even close to mature yet.

If someone wanted to work with the systemd project to cover all of
Debian's requirements for a simple network management facility, I think
that would be a very worthwhile thing to do.  But there's a lot of work to
do.

NetworkManager is closer and *could* be made to handle everything that
ifupdown does now, but it's substantially more complex than ifupdown, and
speaking as someone who mostly runs servers, I would definitely object.
ifupdown has a lot of problems, but most of those problems are around use
cases more complex than bringing up a single interface with either DHCP or
a static IP address, with no wireless involved.

I realize that doing that well is not horribly challenging, but that is
the most common server use case (and even desktop), and ifupdown does it
quite well.  I don't want to lose that, and I don't want to add a bunch of
complexity in order to satisfy that case.  I think there will always be a
place for a very *simple* system to handle that case with some pre and
post hooks for things like iptables rule installation.

I think part of the problem with ifupdown is that it's trying to do too
much.  It's trying to handle all possible network configurations, and some
of them (such as dynamic wireless with WPA and multiple known wireless
networks) are *way* outside of its original design and data model.  So it
struggles.  It's also not particularly adept with the new way that
networks are modeled in the kernel.

That doesn't make it a bad tool, but I think it means that we should
provide more guidance about what things it does well and what things it
does poorly.

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


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



Re: identifying unused manually installed packages

2014-03-28 Thread Sven Bartscher
On Fri, 28 Mar 2014 09:05:49 +0800
Paul Wise  wrote:

> On Fri, Mar 28, 2014 at 5:36 AM, Sven Bartscher wrote:
> 
> > Also I'm not really sure if this is even a good idea, or if there is
> > maybe another program already present which does already identify
> > unused, manually installed packages and I just didn't find it.
> 
> deborphan seems like a similar package:
> 
> https://packages.debian.org/stable/deborphan

I looked at it but don't really get how it guesses which packages are
unneeded. It seems to only suggest leafs (of the dependency tree) but
it doesn't suggest all leafs for removal. It doesn't seem like it is
looking at timestamps.

Can anyone tell me how it is searching for unneeded packages?

While trying some stuff with my script I saw that most (maybe all)
desktop applications, which have a menu entry, won't be found, because
their .desktop files are frequently accessed.
So I think following this approach isn't really worth the afford.
> 
> -- 
> 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: 
> https://lists.debian.org/caktje6exk2ivaleescok+6tvq5dqx_oxhyk0pll5rh9c9bo...@mail.gmail.com
> 


signature.asc
Description: PGP signature


Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)

2014-03-28 Thread Kevin Toppins
On 28 Mar 2014 03:40, Olav Vitters wrote:
[...]
> > I can tell you right now, it is *vastly more difficult* to try to
> > adapt programs modified to work with systemd in their current state,
> > than it is to *revert* those programs to their pre-systemd state.
>
> You're so certain while so utterly wrong on so many levels it is pretty
> amusing and embarrassing at the same time. You said you don't easily get
> offended, but hopefully you do pickup some learnings here.


Did you understand that...

There are (at least) two paths to take here, and this is referring to
the more difficult of the two.  The easier choice is the reversion
then selective upgrade path.

I did go on to explain why the first path was more difficult.  Did you
consider what I said there?


Please, put why I'm so utterly wrong into writing here and let's see
what you understand.


-Kev


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadkoaxhnleetyo6-fgjqujaryhnq8nv6kaxu8bazyudvzvr...@mail.gmail.com



Re: systemd patent fees - who pays?

2014-03-28 Thread Wookey
+++ Alastair McKinstry [2014-03-28 12:45 +]:
> 
> 
> Software patents in Europe is a mess: the understanding I have from IP
> lawyers
> is that
> (1) software patents have no legal standing in Europe.
> (2) The EPO continues to issue them.
> 
> That is, people get "European Software Patents" on the basis that someday
> they may be worth something, and if you haven't patented / tried patenting
> your 'invention', someone else will.
> 
> Can you point to actual case law of a software patent being upheld in
> Europe?
> (as opposed to member states)

No, that's a good point, and as Phil points out, best discussed
elsewhere, so I'll leave it at that.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140328132056.gs10...@stoneboat.aleph1.co.uk



Re: systemd patent fees - who pays?

2014-03-28 Thread Alastair McKinstry

On 28/03/2014 12:18, Wookey wrote:
> +++ Adrien CLERC [2014-03-28 12:17 +0100]:
>
>> No one in Europe. There's no such thing as software patent here. Yet. I
>> hope this will stay forever.
>> (And yes, maybe I'm wrong, but please enlighten me!)
> You are wrong. This is a common misconception, amongst geeks, but there
> are thousands of software patents registered in Europe. It is quite a
> lot harder to use them agressively than it is in the USA, as we don't
> have anything quite a dumb as jury trials in East Marshall, but if you
> follow, for example, the samsung/apple lawsuits round the world or case
> law on microsoft's FAT patents, you will see some pretty bad stuff has
> gone on here too.

Software patents in Europe is a mess: the understanding I have from IP
lawyers
is that
(1) software patents have no legal standing in Europe.
(2) The EPO continues to issue them.

That is, people get "European Software Patents" on the basis that someday
they may be worth something, and if you haven't patented / tried patenting
your 'invention', someone else will.

Can you point to actual case law of a software patent being upheld in
Europe?
(as opposed to member states)

regards
Alastair

> Thinking that this problem is null here is very wrongheaded. It's just
> significantly less awful than America, which isn't a very high bar to
> pass.
>
> This is quite a good historical summary (depite being by an IP lawyer):
> http://ipkitten.blogspot.co.uk/2012/10/the-mess-that-is-european-software.html
>
> And this is info we free software people will find informative:
> http://en.swpat.org/wiki/Software_patents_exist_in_Europe,_mostly
>
> Wookey

-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
A decent provision for the poor is the true test of civilization.
~Samuel Johnson, Boswell: Life of Johnson


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53356ecf.4080...@sceal.ie



Re: systemd patent fees - who pays?

2014-03-28 Thread Wookey
+++ Adrien CLERC [2014-03-28 12:17 +0100]:

> No one in Europe. There's no such thing as software patent here. Yet. I
> hope this will stay forever.
> (And yes, maybe I'm wrong, but please enlighten me!)

You are wrong. This is a common misconception, amongst geeks, but there
are thousands of software patents registered in Europe. It is quite a
lot harder to use them agressively than it is in the USA, as we don't
have anything quite a dumb as jury trials in East Marshall, but if you
follow, for example, the samsung/apple lawsuits round the world or case
law on microsoft's FAT patents, you will see some pretty bad stuff has
gone on here too.

Thinking that this problem is null here is very wrongheaded. It's just
significantly less awful than America, which isn't a very high bar to
pass.

This is quite a good historical summary (depite being by an IP lawyer):
http://ipkitten.blogspot.co.uk/2012/10/the-mess-that-is-european-software.html

And this is info we free software people will find informative:
http://en.swpat.org/wiki/Software_patents_exist_in_Europe,_mostly

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140328121855.gr10...@stoneboat.aleph1.co.uk



Re: systemd patent fees - who pays?

2014-03-28 Thread Sune Vuorela
On 2014-03-28, Sebastian Feld  wrote:
> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:

Citation needed.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/lh3pjj$96b$1...@ger.gmane.org



Re: systemd patent fees - who pays?

2014-03-28 Thread Philip Hands
Sebastian Feld  writes:

> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:

Have you read this:

  https://www.debian.org/legal/patent

in particular, point 3.

Having read that, I would suggest that either:

   your concerns are based on a concrete risk to Debian, in which case
   you should not be discussing them here if you have Debian's best
   interests at heart,

   or they have no basis in legal fact (I'm guessing that you're not a
   lawyer, as you didn't cite which jurisdiction you thought your
   assertion might apply, or any other salient details) in which case
   they don't really tell us anything.

Either way, they don't belong here.

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://ftp.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpLzKsuvrkTZ.pgp
Description: PGP signature


Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Josselin Mouette
Le vendredi 28 mars 2014 à 11:45 +, Thorsten Glaser a écrit : 
> Paul Wise  debian.org> writes:
> 
> > On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:
> > 
> > > Alternatively, we could make NetworkManager the default.
> > > It is already here, it works, and it doesn’t have such problems.
> > 
> > Or systemd-networkd.
> 
> I surely hope the both of you are kidding.

The only joke is to be stuck with ifupdown and its design in total
contradiction with the current way the kernel works.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


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



Re: systemd patent fees - who pays?

2014-03-28 Thread Thibaut Paumard
Le 28/03/2014 11:40, Sebastian Feld a écrit :
> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:

Patent infringement claims by big companies are often FUD.

The right channel if you really want to discuss this (rather than
trolling) is: pate...@debian.org

See: https://www.debian.org/legal/patent
and: https://www.debian.org/reports/patent-faq

Cheers.




signature.asc
Description: OpenPGP digital signature


Re: How to create a debian x32 image?

2014-03-28 Thread Ian Campbell
On Fri, 2014-03-28 at 11:47 +, Thorsten Glaser wrote:
> Adam Borowski  angband.pl> writes:
> 
> > You don't need to jump through those multistrap hoops anymore.  You need
> to
> > recompile the kernel with CONFIG_X86_X32=y, but after that you can use any
> 
> Could this *please* become the default in linux-image-3.14-1-amd64?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708070 is pretty clear
about the reasons for not doing so.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1396007822.8670.34.ca...@kazak.uk.xensource.com



Re: How to create a debian x32 image?

2014-03-28 Thread Jonas Smedegaard
Quoting Thorsten Glaser (2014-03-28 12:47:26)
> Adam Borowski  angband.pl> writes:
>
>> You don't need to jump through those multistrap hoops anymore.  You 
>> need to recompile the kernel with CONFIG_X86_X32=y, but after that 
>> you can use any
>
> Could this *please* become the default in linux-image-3.14-1-amd64?

Try talk to the kernel team instead of here - either via a bugreport or 
through their dedicated list.


 - 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: dist-upgrade strangeness: dependencies not deconfigured

2014-03-28 Thread Thorsten Glaser
Norbert Preining  logic.at> writes:

> In the trigger program we already check that texlive base is in proper
> state (ii in dpkg listing), but that seems not to be enough.

ISTR reading somewhere that Depends do not mean that the dependency is
always configured before the package depending on it is configured, but
only that it once was configured successfully.

The difference can be annoying, yes. Especially as such things are
very hard to test – or even think of, in the first place.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140328t125008-...@post.gmane.org



Re: How to create a debian x32 image?

2014-03-28 Thread Thorsten Glaser
Adam Borowski  angband.pl> writes:

> You don't need to jump through those multistrap hoops anymore.  You need
to
> recompile the kernel with CONFIG_X86_X32=y, but after that you can use any

Could this *please* become the default in linux-image-3.14-1-amd64?

Thanks,
//mirabilos, eagerly awaiting x32


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140328t124714-...@post.gmane.org



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Thorsten Glaser
Paul Wise  debian.org> writes:

> On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:
> 
> > Alternatively, we could make NetworkManager the default.
> > It is already here, it works, and it doesn’t have such problems.
> 
> Or systemd-networkd.

I surely hope the both of you are kidding.

bye,
//mirabilos


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140328t124555-...@post.gmane.org



Re: systemd patent fees - who pays?

2014-03-28 Thread Adrien CLERC
Le 28/03/2014 11:40, Sebastian Feld a écrit :
> Now that Redhat and Suse have been contacted by ORACLE regarding to
> licensing the SMF patents a question arises for Debian:
>
> SystemD violates a couple of patents SUN Microsystems filed for their
> SMF system used in Solaris.
>
> Now, who is going to pay the patent and license fees for each Debian
> installation which uses SystemD?
>
> Seb
No one in Europe. There's no such thing as software patent here. Yet. I
hope this will stay forever.
(And yes, maybe I'm wrong, but please enlighten me!)

Adrien


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53355a3f.5040...@antipoul.fr



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Matt Grant
Hi Andrew,

I am willing to co-maintain it with you and evolve it. Previously I have
worked professionally as a router programmer, and have contributed to
Quagga/Zebra OSPF.

> Please also note that's there's no point in rewriting ifupdown from
> scratch to provide the same interface; the existing code is good enough
> for what it does currently, it just needs to be improved.
> Unfortunately, I don't have enough time currently to implement
> functionality I'd like to, or to fix some issues which bother me and
> other people.

OK, I agree with this to.  Too much does depend on it to rip it out. It
has to be kept backwards compatible.  

Some good work has been done since wheezy (or squeeze) dropping the need
for Linux 2.2.x sub-interface names like 'eth0:0' being required to
bring up extra interface addresses.  Are they still required for
kFreeBSD and GNU/HURD?  We do need to keep old /etc/network/interfaces
files working :-)

Would interface state file business be a good place to look at first?  I
believe I have some good ideas on how it should be done.  It would be
good to wiki them first, and other possible design changes, and see what
others have to contribute.

>From netscript, I have split the iptables stuff in netscript-2.4 into
its own package netscript-ipfilter. That is the most important stuff in
there now, and has to be stand alone from network configuration to
benefit most systems. 

Its a better alternative to eg iptables-persistent as it keeps a saved
history of so many versions, and provides roll back support, 'helper'
chains for IPv6/IPv4 ICMP filtering, border router address checking etc
(more important now everyone is getting an IPv6 subnet, no NAT). Not to
knock anything, other systems may be better depending on your tastes for
firewall/packet filtering.  Nftables are coming to replace iptables in
the kernel.

Lets get some more sense into ifupdown, making it more versatile and
take the corners off it operationally.  I'd like to be able to send
netscript to its grave in a few years :-)

Regards,

Matt Grant




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1396004493.16475.72.ca...@moriah.internal.anathoth.net



systemd patent fees - who pays?

2014-03-28 Thread Sebastian Feld
Now that Redhat and Suse have been contacted by ORACLE regarding to
licensing the SMF patents a question arises for Debian:

SystemD violates a couple of patents SUN Microsystems filed for their
SMF system used in Solaris.

Now, who is going to pay the patent and license fees for each Debian
installation which uses SystemD?

Seb
-- 
Sebastian Feld - IT security expert


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cahnbegkvbos0bqm06av-7bvfrefv2tazetqp8g4ojwmvqnq...@mail.gmail.com



Bug#742864: ITP: openjdk-8 -- OpenJDK 8 - Open source implementation of the Java Platform Standard Edition 8

2014-03-28 Thread Emmanuel Bourg
Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: openjdk-8
  Version : 8u0~b132
  Upstream Author : Oracle Corporation
* URL : http://openjdk.java.net
* License : GPL-2 with Classpath Exception
  Programming Lang: Java, C++
  Description : OpenJDK 8 - Open source implementation of the Java
Platform Standard Edition 8

OpenJDK 8 is the open source implementation of the Java Platform
Standard Edition 8. It contains the Java runtime and the developer tools
necessary to create and execute Java 8 applications.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/533551c8.4030...@apache.org



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Paul Wise
On Fri, Mar 28, 2014 at 5:28 PM, Josselin Mouette wrote:

> Alternatively, we could make NetworkManager the default.
> It is already here, it works, and it doesn’t have such problems.

Or systemd-networkd.

-- 
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: 
https://lists.debian.org/CAKTje6Hzsmc=_w4dfzfasxuvj4fu64nhfz33rh1-kygv4vg...@mail.gmail.com



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Josselin Mouette
Le vendredi 28 mars 2014 à 20:23 +1300, Matt Grant a écrit : 
> I sincerely would like to work with the ifupdown maintainer and
> systemd/udev crew to work all this out.  A basic level/interface of
> functionality for replaceable network configuration packages would be
> nice.

Alternatively, we could make NetworkManager the default.
It is already here, it works, and it doesn’t have such problems.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


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



Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)

2014-03-28 Thread Cameron Norman
El Fri, 28 de Mar 2014 a las 1:19 AM, Olav Vitters  
escribió:

On Wed, Mar 26, 2014 at 11:38:40AM -0500, Kevin Toppins wrote:
 On 26 March 2014 10:13, Cameron Norman  
wrote:

 [...]
 > That is pretty much impossible, according to the developers of 
the logind
 > API and its single implementation. Perhaps a subset of the logind 
API for
 > use by desktop environments / compositors would be more useful in 
this init
 > and OS portability predicament. I think Matthias Clasen, a GNOME 
developer,
 > actually recently expressed interest in this from a portable 
window manager

 > and compositor's perspective.


Ryan Lortie said he'd work with others on some minimal logind like API
during 3.14 cycle. But focussed on entire GNOME stack, not just
gnome-shell. Complication being GDM (=extra work). Implementation on
non-Linux to be done by those developers (FreeBSD, etc; they seems to 
be

ok with that)



Thank you, that was who I was thinking of.

Best regards,
--
Cameron Norman


Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)

2014-03-28 Thread Olav Vitters
On Wed, Mar 26, 2014 at 11:38:40AM -0500, Kevin Toppins wrote:
> On 26 March 2014 10:13, Cameron Norman  wrote:
> [...]
> > That is pretty much impossible, according to the developers of the logind
> > API and its single implementation. Perhaps a subset of the logind API for
> > use by desktop environments / compositors would be more useful in this init
> > and OS portability predicament. I think Matthias Clasen, a GNOME developer,
> > actually recently expressed interest in this from a portable window manager
> > and compositor's perspective.

Ryan Lortie said he'd work with others on some minimal logind like API
during 3.14 cycle. But focussed on entire GNOME stack, not just
gnome-shell. Complication being GDM (=extra work). Implementation on
non-Linux to be done by those developers (FreeBSD, etc; they seems to be
ok with that)

> I can tell you right now, it is *vastly more difficult* to try to
> adapt programs modified to work with systemd in their current state,
> than it is to *revert* those programs to their pre-systemd state.

You're so certain while so utterly wrong on so many levels it is pretty
amusing and embarrassing at the same time. You said you don't easily get
offended, but hopefully you do pickup some learnings here.

-- 
Regards,
Olav (GNOME release team)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140328081951.ga17...@bkor.dhs.org



Re: Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Andrew Shadura
Hello,

On Fri, 28 Mar 2014 20:23:15 +1300
Matt Grant  wrote:

> I KNOW MY STUFF COULD/SHOULD BE BETTER!  Maybe I should reimplement a
> lot of it using only what is provided by perl-base and /bin/sh, but
> lets get some sense here please.

Thanks for the rant, it's been considered. I hope you feel better now,
do you? Good. When you calm down and have anything useful to contribute,
you're welcome.

Please also note that's there's no point in rewriting ifupdown from
scratch to provide the same interface; the existing code is good enough
for what it does currently, it just needs to be improved.
Unfortunately, I don't have enough time currently to implement
functionality I'd like to, or to fix some issues which bother me and
other people.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature


Ifupdown dysfunctional, is a Provides: interface possible please?

2014-03-28 Thread Matt Grant
Hi!

I am the developer of netscript-2.4, an alternative network
configuration system for Debian written in /bin/bash - quite old.  

First of all, though, my stuff is not the glorious gloopiest best. I
have split the iptables stuff out to netscript-ipfilter, better than
iptables-persistent I must say though!

But I still persist with it as I find some things about ifupdown rather
not good.

eg:

web: -root- [~] 
# ip link
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN mode
DEFAULT 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast
state UP mode DEFAULT qlen 1000
link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff

web: -root- [~] 
# ip link set dev eth0 down

web: -root- [~] 
# ifup eth0
ifup: interface eth0 already configured

web: -root- [~] 
# ip link show dev eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state DOWN mode
DEFAULT qlen 1000
link/ether 52:54:00:97:5a:d6 brd ff:ff:ff:ff:ff:ff

web: -root- [~] 
# 

Eh what???

ifupdown also cannot add an additional address/subnet to an interface
without shutting the interface down and restarting it.  Kernel allows
it, why not?

My package does provide command line compatibility though, and gives
ifupdown as a Provides:

I have found that the version dependency of resolvconf on ifupdown (>=
0.7.5) breaks the Provides on my package...

Also, there is quite some scripting glue going on down in udev...

Have a look at /lib/udev/net.agent

ifupdown also has a whole forest of shell scripts for it in other
packages as well.  Very similar to sysvinit/systemd stuff we have
already gone through.  

One thing that put me off ifupdown quite some time ago was finding that
configured bridges made NFS client mounts on the host wait... who would
implement a bridge with interface listen/wait/STP functionality on a
pure work station or server? Sounds like a router/firewall, and they
should not be nfs mounting by their nature and functionality ... Real
corner case stuff.

I sincerely would like to work with the ifupdown maintainer and
systemd/udev crew to work all this out.  A basic level/interface of
functionality for replaceable network configuration packages would be
nice.

I KNOW MY STUFF COULD/SHOULD BE BETTER!  Maybe I should reimplement a
lot of it using only what is provided by perl-base and /bin/sh, but lets
get some sense here please.

I also compatibility for upgrades is required, but how compatible does
any intentional replacement for ifupdown have to be, especially if the
system a firewall or a router?

Regards,

Matt Grant


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1395991395.16475.25.ca...@moriah.internal.anathoth.net



Re: Bug#742836: syslinux: The Debian package of syslinux 6 breaks compatibility by gratuitously moving files around

2014-03-28 Thread Raphael Hertzog
Control: reopen -1

On Fri, 28 Mar 2014, Daniel Baumann wrote:
> On 03/27/2014 10:49 PM, Raphaël Hertzog wrote:
> > The experimental packages of syslinux move files around and thus breaks
> > all syslinux users that rely on the default (upstream defined) location of
> > the syslinux provided files.
> 
> no. packages like live-build will use syslinux-dev which has everything
> in its normal place.

This still breaks various packages in Debian which depend on syslinux and
expect the files at the normal place. Thus backwards compat is broken.

Can you explain what is the purpose of the change?

Not knowing the purpose, I can hardly suggest an improvement. But maybe
you should use a new package name for the new purpose of the package:
something like syslinux-mbr and keep "syslinux" as the implicit
syslinux-dev that you created.

The changelog has almost no rationale for the changes:

  * Moving syslinux mbr file location to /usr/lib/syslinux/mbr.
  * Moving syslinux-common modules file location to /usr/lib/syslinux-
common/modules.
  * Moving syslinux-common modules file location to /usr/lib/syslinux-
common/modules.
  * Splitting out isolinux into own package for syslinux-installer and
debian-live usage.
  * Splitting out pxelinux into own package for syslinux-installer and
debian-live usage.
  * Splitting out utils into own package to relieve burden on syslinux and
syslinux-common.
  [...]
  * Splitting pseudo architecture-independent files for use by debian-cd
and other development related files out into syslinux-dev package to
relieve burden on syslinux-common (usually installed by anyone using
any of the syslinux, extlinux, isolinux, or pxelinux package) and to
allow debian-live to use architecture-dependent files on non-uploader
architectures.

As I said, it's fine to split files in multiple packages, you can have the new
syslinux package depend on "syslinux-mbr, syslinux-efi, isolinux, pxelinux"
and thus you don't break anything and syslinux-installer (which is not in
Debian apparently) and live-build can benefit from installing only the new
package that they need.

But please don't break other packages when you can easily avoid it.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140328071931.ga9...@x230-buxy.home.ouaza.com