Re: ifupdown2: debconf followup

[Guus Sliepen]

On Sun, Jul 31, 2016 at 06:58:20PM -0700, Roopa Prabhu wrote:

> And, we will be very happy to work towards making ifupdown2
> the default in Debian. If there are ways to make that happen, please let us 
> know.

First, try to make it compatible with 99% of the non-trivial
ifupdown configurations. Why? First, everyone with a trivial network
configuration (like auto eth0; iface eth0 inet dhcp) will not care
about what network configuration tool brings up their network. The
people have a more complex setup will care, and if you make it hard for
them to move to ifupdown2, I think they'll rather stick with ifupdown.
You either have to be able to parse ifupdown's /etc/network/interfaces
or have a way to convert it to whatever new format ifupdown2 requires.

I see one big drawback of ifupdown2, and that is that it's written in
Python. Nothing wrong with that language, but it means it pulls in
dependencies which a minimal install currently doesn't require, which is
not so nice for people running small VMs or embedded devices. 

If ifupdown2 is meant as a drop-in replacement for ifupdown, just fixing
some bugs or adding a few missing features of ifupdown, I'd rather see
those issues addressed in ifupdown. But of course, as one of the
maintainers of ifupdown I'm quite biased :)

> I also heard about some existing mailing list or discussions around solving 
> ifupdown
> problems. We would like to be part of those discussions to see
> if ifupdown2 fits there.

I don't know of such a mailing list... but there's always the BTS.

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


signature.asc
Description: Digital signature

sybase license and openWatcom DFSGness

[Gianfranco Costamagna]

Hi, this is a question mainly for ftpmasters, but I think some public 
discussion here
might be beneficial for me :)

Basically, we thought OpenWatcom license wasn't DFSG for Debain standards, and 
now since
I would like to put Virtualbox back in main, I'm trying to see if some statement
clarifying the license is sufficient to make it dfsg.

I'm adding some pointers to the RFP bug, and to the public discussion that is 
ongoing
upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
https://github.com/open-watcom/open-watcom-v2/issues/271

thanks for reading :)

Gianfranco

Re: sybase license and openWatcom DFSGness

[Paul Wise]

On Mon, Aug 1, 2016 at 5:44 PM, Gianfranco Costamagna wrote:

> Hi, this is a question mainly for ftpmasters, but I think some public 
> discussion here
> might be beneficial for me :)

I didn't see a question in your mail :)

> Basically, we thought OpenWatcom license wasn't DFSG for Debain standards, 
> and now since
> I would like to put Virtualbox back in main, I'm trying to see if some 
> statement
> clarifying the license is sufficient to make it dfsg.

Is there any reason they can't relicense to something more standard?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: sybase license and openWatcom DFSGness

[Ben Finney]

Gianfranco Costamagna  writes:

> Hi, this is a question mainly for ftpmasters, but I think some public
> discussion here might be beneficial for me :)

IMO this is what the ‘debian-legal’ discussion group is for: to save the
many people who read ‘debian-devel’ but don't want intricate discussions
of license effects in the main discussion forum.

If you agree, I think it's better to ask the question instead at
‘debian-legal’.

-- 
 \   “… whoever claims any right that he is unwilling to accord to |
  `\ his fellow-men is dishonest and infamous.” —Robert G. |
_o__)   Ingersoll, _The Liberty of Man, Woman and Child_, 1877 |
Ben Finney

Re: sybase license and openWatcom DFSGness

[Guus Sliepen]

On Mon, Aug 01, 2016 at 09:44:33AM +, Gianfranco Costamagna wrote:

> Hi, this is a question mainly for ftpmasters, but I think some public 
> discussion here
> might be beneficial for me :)
> 
> Basically, we thought OpenWatcom license wasn't DFSG for Debain standards, 
> and now since
> I would like to put Virtualbox back in main, I'm trying to see if some 
> statement
> clarifying the license is sufficient to make it dfsg.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
> https://github.com/open-watcom/open-watcom-v2/issues/271

I don't see that anything has changed in the past ten years, so I don't
think a clarification will do any good. Why does VirtualBox keep relying
on the OpenWatcom provider? There's bcc and faucc. QEMU's SeaBIOS is
compiled with GCC (but looking at the source, all the 16-bit code is in
asm statements). If Sybase doesn't provide a new license, I think it's
better to spend some effort in porting the BIOS to something that
doesn't require OpenWatcom.

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


signature.asc
Description: Digital signature

Re: Re: sybase license and openWatcom DFSGness

[Gianfranco Costamagna]

Hi Paul

>I didn't see a question in your mail :)

would a clear statement from them satisfy Debian standards? or should them 
relicense?

>Is there any reason they can't relicense to something more standard?

Not sure, big company, legal issues, difficult to track people for changing it, 
I don't really know

I can quote from github issue this statement

"
I'm pretty sure Sybase had been asked in the (now distant) past and refused 
just because they didn't see the point. There is a "draft" version 2 of the 
license, but I'm guessing it can't just be adopted if it hasn't been adopted 
already. However, if someone really thinks they can convince Sybase otherwise, 
give it a try!

One thing to remember, though, is that Sybase doesn't hold copyright over all 
of Open Watcom any longer. Much of the current system has new files that are 
"Copyright Open Watcom contributors" with no attribution to Sybase. Changing 
the license outright to something that isn't just a follow-on to the Open 
Watcom Public License might be tricky.
"

G.



signature.asc
Description: OpenPGP digital signature

Re: ifupdown2: debconf followup

[Marco d'Itri]

On Aug 01, Guus Sliepen  wrote:

> I see one big drawback of ifupdown2, and that is that it's written in
> Python. Nothing wrong with that language, but it means it pulls in
> dependencies which a minimal install currently doesn't require, which is
> not so nice for people running small VMs or embedded devices. 
Indeed. I strongly believe that this is bad enough to disqualify it as 
the default implementation.

We should also think hard about switching to a new default since 
currently many other major distributions are moving to NetworkManager 
and/or systemd-networkd (which nowadays is usable, works well for 
simpler use cases and will be installed on every Debian system anyway).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown2: debconf followup

[Adam Borowski]

On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote:
> On Aug 01, Guus Sliepen  wrote:
> 
> > I see one big drawback of ifupdown2, and that is that it's written in
> > Python. Nothing wrong with that language, but it means it pulls in
> > dependencies which a minimal install currently doesn't require, which is
> > not so nice for people running small VMs or embedded devices. 
> Indeed. I strongly believe that this is bad enough to disqualify it as 
> the default implementation.
> 
> We should also think hard about switching to a new default since 
> currently many other major distributions are moving to NetworkManager 
> and/or systemd-networkd (which nowadays is usable, works well for 
> simpler use cases and will be installed on every Debian system anyway).

For the latter, "installable only with a certain init implementation, and
not portable to any kernel but Linux" doesn't say "every Debian system" to
me.

-- 
An imaginary friend squared is a real enemy.

Re: ifupdown2: debconf followup

[Marco d'Itri]

On Aug 01, Adam Borowski  wrote:

> > We should also think hard about switching to a new default since 
> > currently many other major distributions are moving to NetworkManager 
> > and/or systemd-networkd (which nowadays is usable, works well for 
> > simpler use cases and will be installed on every Debian system anyway).
> For the latter, "installable only with a certain init implementation, and
> not portable to any kernel but Linux" doesn't say "every Debian system" to
> me.
Sorry, what I actually meant was "every non-toy Debian system".

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Re: sybase license and openWatcom DFSGness

[Gianfranco Costamagna]

(I'll drop -devel starting from next email, following up on debian-legal 
isntead)
>If you agree, I think it's better to ask the question instead at
>‘debian-legal’.

Hi Debian-Legal list :)

forwarding the discussion from -devel here

Basically, we thought OpenWatcom license wasn't DFSG for Debain standards, and 
now since
I would like to put Virtualbox back in main, I'm trying to see if some statement
clarifying the license is sufficient to make it dfsg.

I'm adding some pointers to the RFP bug, and to the public discussion that is 
ongoing
upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376431
https://github.com/open-watcom/open-watcom-v2/issues/271

thanks for reading :)

Gianfranco



signature.asc
Description: OpenPGP digital signature

Re: ifupdown2: debconf followup

[Guus Sliepen]

On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote:

> We should also think hard about switching to a new default since 
> currently many other major distributions are moving to NetworkManager 
> and/or systemd-networkd (which nowadays is usable, works well for 
> simpler use cases and will be installed on every Debian system anyway).

Last time I looked at it, systemd-networkd required several
configuration files just to bring up a single interface. I can't say it
was a very user-friendly experience. But perhaps things are better now?

I'd say a good starting point would be to try to switch the installer to
configuring NetworkManager or systemd-networkd, instead of generating a
/etc/network/interfaces file. Once there is such a pre-generated
configuration, a barrier has already been overcome; it's easier to tweak
something that's already there than to write it from scratch.

How would it work on Hurd and kFreeBSD?

Ideally, it would be nice to have something like "ifconfig-persistent",
equivalent to netfilter-persistent but remembering and restoring
interface configuration. It's quite a hard problem though; statically
configured interfaces are easy, but for dynamically configured ones
you'd have to track down which daemons are managing which interfaces
(dhclient, wpa-supplicant, network-manager etc.) and have do the right
thing to restart them at boot when necessary. Instead of managing this
problem itself, it could just create systemd-networkd or NetworkManager
configuration at shutdown time. The advantage would be that the user
doesn't need to know what the configuration paradigm du jour is, and can
just configure things once in whatever way they like, and be sure that
their settings are not lost on reboot.

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


signature.asc
Description: Digital signature

Re: sybase license and openWatcom DFSGness

[Adam Borowski]

On Mon, Aug 01, 2016 at 12:24:12PM +0200, Guus Sliepen wrote:
> Why does VirtualBox keep relying on the OpenWatcom provider?  There's bcc
> and faucc.

AFAIK, VirtualBox upstream decided to use non-standard OpenWatcom extensions.

> QEMU's SeaBIOS is compiled with GCC (but looking at the source, all the
> 16-bit code is in asm statements).  If Sybase doesn't provide a new
> license, I think it's better to spend some effort in porting the BIOS to
> something that doesn't require OpenWatcom.

These days, most non-historic operating systems can boot on EFI, meaning
that even failing to ship a 16-bit BIOS could be reasonable.


Meow!
-- 
An imaginary friend squared is a real enemy.

Re: Re: sybase license and openWatcom DFSGness

[Gianfranco Costamagna]

Hi Guus

>I don't see that anything has changed in the past ten years, so I don't
>think a clarification will do any good. Why does VirtualBox keep relying
>on the OpenWatcom provider? There's bcc and faucc. QEMU's SeaBIOS is
>compiled with GCC (but looking at the source, all the 16-bit code is in
>asm statements). If Sybase doesn't provide a new license, I think it's
>better to spend some effort in porting the BIOS to something that
>doesn't require OpenWatcom.

forwarding the answer from upstream

"We moved from bcc to OpenWatcom because bcc is just not good enough - it only 
handles one limited memory model.
(Can't remember the C terms, but basically everything in one 8086 segment.)
https://www.virtualbox.org/pipermail/vbox-dev/2012-December/011105.html
Re faucc
We are not allowed to touch SeaBIOS for licence reasons.  Not our decision.
And the problem with porting the BIOS, well simply that it requires time we do 
not have for that purpose."

I don't know asm well enough to remember and understand completely such above 
statement :)

G.



signature.asc
Description: OpenPGP digital signature

Bug#833140: RFP: embroidermodder -- Free machine embroidery software

[Balint Reczey]

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

* Package name: embroidermodder
  Version : 2.0
* URL : http://embroidermodder.org
* License : Zlib
  Programming Lang: C/C++
  Description : Free machine embroidery software
 Embroidermodder is a free machine embroidery software program.
 .
 Features:
  - edit and create embroidery designs
 .
  - estimate the amount of thread and machine time needed to stitch
 a design
 .
  -convert embroidery files to a variety of formats
 .
  -upscale or downscale designs

--
 One could embroider awesome Debian apparel using this package ;-):
 http://embroidermodder.org/features.html

Re: ifupdown2: debconf followup

[Adam Borowski]

On Mon, Aug 01, 2016 at 12:42:39PM +0200, Marco d'Itri wrote:
> On Aug 01, Adam Borowski  wrote:
> 
> > > We should also think hard about switching to a new default since 
> > > currently many other major distributions are moving to NetworkManager 
> > > and/or systemd-networkd (which nowadays is usable, works well for 
> > > simpler use cases and will be installed on every Debian system anyway).
> > For the latter, "installable only with a certain init implementation, and
> > not portable to any kernel but Linux" doesn't say "every Debian system" to
> > me.
> Sorry, what I actually meant was "every non-toy Debian system".

As any non-toy system needs reliable, resilient and predictable init scripts
free of bugs like:
* force-unmounting your RAID when you manually mount it degraded
* killing properly backgrounded filesystem maintenance if you log off
  (intentionally or just due to a flaky network connection, etc)
I'm not sure what non-toy systems you're talking about.


(Sorry for responding to an obvious troll post -- responding just in case it
was actually somehow meant as serious.)


-- 
An imaginary friend squared is a real enemy.

Re: sybase license and openWatcom DFSGness

[Christian Seiler]

On 08/01/2016 12:56 PM, Gianfranco Costamagna wrote:
> We are not allowed to touch SeaBIOS for licence reasons.  Not our decision.

Maybe I don't quite understand what VirtualBox upstream meant by this
sentence, but if the SeaBIOS license does not allow modification,
then it would not be DFSG-free, so the fact that VirtualBox is in
contrib would actually be an error, because it should rather be in
non-free. And that would be irrespective of the compiler used.

Am I missing something here?

Regards,
Christian

Re: sybase license and openWatcom DFSGness

[Gianfranco Costamagna]

Hi,

>Maybe I don't quite understand what VirtualBox upstream meant by this
>sentence, but if the SeaBIOS license does not allow modification,
>then it would not be DFSG-free, so the fact that VirtualBox is in
>contrib would actually be an error, because it should rather be in
>non-free. And that would be irrespective of the compiler used.
>
>Am I missing something here?


SeaBIOS license is not used by VirtualBox, and I think a good reason for
excluding it is:
"SeaBIOS may be distributed under the terms of the GNU LGPLv3 license. Both 
source code and binaries are available."

Virtualbox is under GPL-2 with a lot of exception, allowing it to be used with 
MPL, Apache 2.0, OpenSSL.

So, LGPL-3 will be too restrictive I think for them.

G.

Re: sybase license and openWatcom DFSGness

[Guus Sliepen]

On Mon, Aug 01, 2016 at 11:24:46AM +, Gianfranco Costamagna wrote:

> SeaBIOS license is not used by VirtualBox,

I was just mentioning it because it is a BIOS and it is compiled by GCC,
so it was an argument that OpenWatcom is not a requirement to build
working BIOS code.

> and I think a good reason for
> excluding it is:
> "SeaBIOS may be distributed under the terms of the GNU LGPLv3 license. Both 
> source code and binaries are available."
> 
> Virtualbox is under GPL-2 with a lot of exception, allowing it to be used 
> with MPL, Apache 2.0, OpenSSL.
> 
> So, LGPL-3 will be too restrictive I think for them.

It should be fine to combine GPL-2 and LGPL-3. Also, if the BIOS is just
a separate thing from the virtual machine emulator itself, there should
be no problem having wildly different licenses. But of course, if
VirtualBox's emulator code heavily depends on their specific BIOS,
things are different.

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


signature.asc
Description: Digital signature

Re: ifupdown2: debconf followup

[Lars Wirzenius]

On Mon, Aug 01, 2016 at 12:42:39PM +0200, Marco d'Itri wrote:
> Sorry, what I actually meant was "every non-toy Debian system".

Marco,

we get that you have strong preferences. However, could you please
avoid inflammatory language when talking about anything that isn't
according to your preferences?

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: MBF: Removing old GNOME python bindings

[Emilio Pozuelo Monfort]

On 29/07/16 00:20, Jonas Smedegaard wrote:
> Quoting Emilio Pozuelo Monfort (2016-07-28 23:29:00)
>> It is high time that we remove the old GNOME python bindings. We have 
>> had the "new" GObject introspection support since at least Squeeze. 
>> The old ones are completely unmaintained and unsupported.
>>
>> I'd like to get gnome-python, gnome-python-extras, pyorbit, 
>> nautilus-python and pygtksourceview removed from testing for the 
>> Stretch release. Most of the gnome-python and gnome-python-extras 
>> binaries have already been removed. This is the final push.
>>
>> Removing pygtk and pygobject-2 may be unreasonable for Stretch, so if 
>> that can't happen we'll file bugs soon after the Stretch release (or 
>> file them earlier and bump the severity after the release) to get it 
>> done for Buster.
>>
>> For gnome-python{,-extras}, pyorbit, nautilus-python and 
>> pygtksourceview there are 54 reverse dependencies, and only 2 of them 
>> are key packages. One of those (cinnamon) doesn't actually need to 
>> depend on any of these packages and can just drop the dependency, and 
>> the other (hamster-applet) will need to be updated to a new upstream 
>> version or get removed as well.
> 
> The Sugar project is actively working towards migration from pygtk to 
> pygobject but is unlikely to finish that work before the freeze of 
> Stretch, unfortunately.

I see that some of sugar has already been ported, e.g. sugar-toolkit-gtk3. Is
there really no way things can be ported in time? These modules have been
deprecated for years and we'd really like to get rid of them.

Also, I wonder if we really need three versions of sugar. The only remaining
rdep for 0.88 seems to be sugar-moon-activity. That seems unmaintained: we have
version 11 while upstream has 17, and the last maintainer activity was in 2010.
Thus I have filed an RC bug on sugar-base-0.88 to get it out of Stretch.

As for sugar-toolkit 0.98, there's only sugar-calculate-activity and
sugar-presence-service (last upstream activity 2011, package description says it
is deprecated) still depending on it. Maybe we should remove those as well so we
can kill sugar 0.98?

Getting those fixed or removed would mean that we don't have to ship multiple
versions of sugar, and that we can get rid of the static GNOME python bindings.

Cheers,
Emilio

Re: [Pkg-sugar-devel] MBF: Removing old GNOME python bindings

[Jonas Smedegaard]

Quoting Emilio Pozuelo Monfort (2016-08-01 16:43:06)
> On 29/07/16 00:20, Jonas Smedegaard wrote:
>> Quoting Emilio Pozuelo Monfort (2016-07-28 23:29:00)
>>> It is high time that we remove the old GNOME python bindings. We 
>>> have had the "new" GObject introspection support since at least 
>>> Squeeze. The old ones are completely unmaintained and unsupported.
>>>
>>> I'd like to get gnome-python, gnome-python-extras, pyorbit, 
>>> nautilus-python and pygtksourceview removed from testing for the 
>>> Stretch release. Most of the gnome-python and gnome-python-extras 
>>> binaries have already been removed. This is the final push.
>>>
>>> Removing pygtk and pygobject-2 may be unreasonable for Stretch, so 
>>> if that can't happen we'll file bugs soon after the Stretch release 
>>> (or file them earlier and bump the severity after the release) to 
>>> get it done for Buster.
>>>
>>> For gnome-python{,-extras}, pyorbit, nautilus-python and 
>>> pygtksourceview there are 54 reverse dependencies, and only 2 of 
>>> them are key packages. One of those (cinnamon) doesn't actually need 
>>> to depend on any of these packages and can just drop the dependency, 
>>> and the other (hamster-applet) will need to be updated to a new 
>>> upstream version or get removed as well.
>> 
>> The Sugar project is actively working towards migration from pygtk to 
>> pygobject but is unlikely to finish that work before the freeze of 
>> Stretch, unfortunately.
>
> I see that some of sugar has already been ported, e.g. 
> sugar-toolkit-gtk3. Is there really no way things can be ported in 
> time? These modules have been deprecated for years and we'd really 
> like to get rid of them.

Sugar is an environment, where you can execute so-called "activities".  
Hundreds of activities exist, where some of them is packaged for Debian.

Core Sugar components now uses python-sugar3 a.k.a. sugar-toolkit-gtk3, 
but Sugar as an environment (called "Sucrose") is still defined as 
including *both* the modern python-sugar3 *and* legacy python-sugar. 
Many activities have not yet migrated yet, and Sugar without legacy 
support will provide a severely broken Sugar experience.


> Also, I wonder if we really need three versions of sugar.

I believe there is currently 2 (not 3) versions of Sugar in Debian.


> The only remaining rdep for 0.88 seems to be sugar-moon-activity. That 
> seems unmaintained: we have version 11 while upstream has 17, and the 
> last maintainer activity was in 2010. Thus I have filed an RC bug on 
> sugar-base-0.88 to get it out of Stretch.

Thanks.  I simply didn't take time to do that because it involved 
packages maintained outside of the Sugar team (that Moon actitivy).


> As for sugar-toolkit 0.98, there's only sugar-calculate-activity and 
> sugar-presence-service (last upstream activity 2011, package 
> description says it is deprecated) still depending on it. Maybe we 
> should remove those as well so we can kill sugar 0.98?

No.  That package is part of legacy support in Sugar, it is discouraged 
to develop any new activities based on that library, but there are 
hundreds of Sugar activities still depending on it.

Yes, most of those activities are not in Debian - just as most of shell 
scripts depending on Zsh is not in Debian, but it would still be a bad 
idea to kick that package judging from its reverse dependencies (I 
guess: I am not a Zsh user myself).


> Getting those fixed or removed would mean that we don't have to ship 
> multiple versions of sugar, and that we can get rid of the static 
> GNOME python bindings.

Kicking Sugar 0.88 would indeed mean that we ship only a single version 
of Sugar - but kicking python-sugar would cripple Sugar, just as I guess 
kicking gtk2 would cripple GNOME.


 - 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: ifupdown2: debconf followup

[Simon McVittie]

On Mon, 01 Aug 2016 at 12:40:37 +0200, Adam Borowski wrote:
> On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote:
> > We should also think hard about switching to a new default since 
> > currently many other major distributions are moving to NetworkManager 
> > and/or systemd-networkd (which nowadays is usable, works well for 
> > simpler use cases and will be installed on every Debian system anyway).
> 
> For the latter, "installable only with a certain init implementation, and
> not portable to any kernel but Linux" doesn't say "every Debian system" to
> me.

"Every Debian system" was certainly overreaching, but Marco has a valid
point: default installations of Debian on its recommended kernel will have
systemd(-networkd). If you take steps to use a non-default init system,
or if you choose to install with a non-recommended kernel, then I think
it's reasonable to expect that other defaults will not necessarily suit
you either; but since you have already demonstrated that you are able
to choose non-default options, you can continue to do so.

Defaults should err on the side of the option we would recommend to
people who don't have (enough knowledge to have) special requirements
or a strong preference, because those are precisely the people who won't
or can't choose something more suitable for their needs.

S
(currently using ifupdown on remote server because I haven't got round
to changing it, systemd-networkd on home server, and NetworkManager
on everything with Debian and wifi)

Re: ifupdown2: debconf followup

[Simon McVittie]

On Mon, 01 Aug 2016 at 12:48:26 +0200, Guus Sliepen wrote:
> Last time I looked at it, systemd-networkd required several
> configuration files just to bring up a single interface.

What were the others, beyond the .network file? This is live configuration
from my home server, which has two network interfaces and I didn't want
it to bring up the other:

# /etc/systemd/network/lan.network
[Match]
Path=pci-:03:00.0

[Network]
DHCP=yes

The simplest possible, for "be a DHCP client on all interfaces with
no match configured earlier than this in alphabetical order", is
something like this:

# /etc/systemd/network/zz_default_dhcp.network
[Match]
[Network]
DHCP=yes

I know systemd-networkd also reads *.link files, but they aren't necessary
in cases this simple. They might be needed for WLANs, but if you're dealing
with WLANs it's time to seriously consider NetworkManager (or possibly
ConnMan, but I'm not sure I'd recommend that as a default).

> I'd say a good starting point would be to try to switch the installer to
> configuring NetworkManager or systemd-networkd, instead of generating a
> /etc/network/interfaces file.

This seems reasonable. I think NM is a better choice than ifupdown for
roaming client devices (e.g. laptops), and systemd-networkd is a good
choice for "infrastructure" devices like servers and NAS boxes.

> How would it work on Hurd and kFreeBSD?

That's up to the people who want to support those non-default kernels,
and I don't think it's reasonable to expect the rest of the distribution
to do that work for them. One possible answer would be to write or adapt
an ifupdown-like tool that works on those kernels and can consume (a
sufficiently large subset of) systemd-networkd .network (and maybe .link)
syntax, and/or NetworkManager /etc/NetworkManager/system-connections/
syntax. If that tool also worked on Linux, as a non-default option for
people who want a non-default init or just don't like the default
tools, so much the better.

systemd-networkd syntax is better-documented and better-suited to a
mental model where you configure interfaces; NetworkManager syntax has
fewer files per network, and is better suited to a mental model where
you configure networks that you can roam to, and "the system" connects
whatever interfaces you have to the networks it can see.

I think this might be a good opportunity to get away from the anti-pattern
of defining a Debian-specific file format, which has a heavy risk of
.

S

Bug#833168: ITP: scala-asm -- Fork of ASM for the Scala Compiler

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: scala-asm
  Version : 5.0.4-scala-3
  Upstream Author : INRIA, France Telecom
* URL : https://github.com/scala/scala-asm
* License : BSD-3-clause
  Programming Lang: Java
  Description : Fork of ASM for the Scala Compiler

This library is a fork of the ASM Java bytecode manipulation and analysis
framework (see libasm-java) modified for the needs of the Scala compiler.
The classes are relocated under the scala.tools.asm package and a small
number of patches were applied to the original sources.

This package is required to upgrade Scala to the latest release.
It'll be maintained by the Java Team.

Re: ifupdown2: debconf followup

[Guus Sliepen]

On Mon, Aug 01, 2016 at 04:43:27PM +0100, Simon McVittie wrote:

> > Last time I looked at it, systemd-networkd required several
> > configuration files just to bring up a single interface.
> 
> What were the others, beyond the .network file? This is live configuration
> from my home server, which has two network interfaces and I didn't want
> it to bring up the other:
> 
> # /etc/systemd/network/lan.network
> [Match]
> Path=pci-:03:00.0
> 
> [Network]
> DHCP=yes

Ah. Either I didn't know that, or things have improved since last time I
used it :)

> > I'd say a good starting point would be to try to switch the installer to
> > configuring NetworkManager or systemd-networkd, instead of generating a
> > /etc/network/interfaces file.
> 
> This seems reasonable. I think NM is a better choice than ifupdown for
> roaming client devices (e.g. laptops), and systemd-networkd is a good
> choice for "infrastructure" devices like servers and NAS boxes.

Although I personally use NM for my laptops, I know that there certainly
are users who don't like it, and it is perfectly possible to configure
wpa-supplicant and/or ifupdown to do whatever NM does. It's not even
very difficult.

> > How would it work on Hurd and kFreeBSD?
> 
> That's up to the people who want to support those non-default kernels,
> and I don't think it's reasonable to expect the rest of the distribution
> to do that work for them. One possible answer would be to write or adapt
> an ifupdown-like tool that works on those kernels and can consume (a
> sufficiently large subset of) systemd-networkd .network (and maybe .link)
> syntax, and/or NetworkManager /etc/NetworkManager/system-connections/
> syntax. If that tool also worked on Linux, as a non-default option for
> people who want a non-default init or just don't like the default
> tools, so much the better.

Well, that sounds like a bad idea to me. By the time you support all the
features of networkd for example, you've just about ported networkd to
that non-Linux platform. If you don't support all the features, having
it look like a systemd.network file is just confusing to users.

The time spent writing such a hypothetical tool would then be better
spent keeping support for ifupdown in the installer for the non-Linux
platforms.

> I think this might be a good opportunity to get away from the anti-pattern
> of defining a Debian-specific file format, which has a heavy risk of
> .

Eh, that comic applies more to systemd than to ifupdown.

Now might be a good time to look at distributions that have adopted
networkd as the default way to configure interfaces, and see how they
fare.

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


signature.asc
Description: Digital signature

Re: ifupdown2: debconf followup

[Marco d'Itri]

On Aug 01, Lars Wirzenius  wrote:

> > Sorry, what I actually meant was "every non-toy Debian system".
> we get that you have strong preferences. However, could you please
> avoid inflammatory language when talking about anything that isn't
> according to your preferences?
Reasonable people should not get "inflamed": I like toys myself and 
I have a lot of them, there is nothing intrinsecally bad in using a toy 
or maintaining one.
But I also know that toys cannot get in the way of real work: there are 
a lot of people here for whom Debian is much more than a toy and I will 
not fail them by optimizing for a fringe use case.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown2: debconf followup

[Marco d'Itri]

On Aug 01, Guus Sliepen  wrote:

> The time spent writing such a hypothetical tool would then be better
> spent keeping support for ifupdown in the installer for the non-Linux
> platforms.
I agree: if the Hurd/kFreeBSD porters will be able to keep sysvinit on 
life support then continuing to use ifupdown will be a minor issue.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: ifupdown2: debconf followup

[Lars Wirzenius]

On Mon, Aug 01, 2016 at 09:01:20PM +0200, Marco d'Itri wrote:
> On Aug 01, Lars Wirzenius  wrote:
> 
> > > Sorry, what I actually meant was "every non-toy Debian system".
> > we get that you have strong preferences. However, could you please
> > avoid inflammatory language when talking about anything that isn't
> > according to your preferences?
> Reasonable people should not get "inflamed": I like toys myself and 
> I have a lot of them, there is nothing intrinsecally bad in using a toy 
> or maintaining one.

It is not unreasonable to interpret your use of the word "toy" to
describe someone else's preferred system as an insult. You can try to
invent meanings and situations that explain away the insult, but I
don't think that changes anything.

If you want to actually work with people, you should try to be
constructive. Being dismissive of others' preferences is
anti-constructive.

It is possible that their opinion of what's good and what's not is
objectively wrong. In that case, you should give the objective
arguments for that. Instead, you say things that reasonable people
find insulting, and the reasonable conclusion is that you're not
interested in being constructive. That's reasonably unfortunate.

I don't want this to become a long subthread, so I'm ending my
participation in it with this mail.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: PGP signature

Re: ifupdown2: debconf followup

[Marc Haber]

On Mon, 1 Aug 2016 12:48:26 +0200, Guus Sliepen 
wrote:
>On Mon, Aug 01, 2016 at 12:31:14PM +0200, Marco d'Itri wrote:
>> We should also think hard about switching to a new default since 
>> currently many other major distributions are moving to NetworkManager 
>> and/or systemd-networkd (which nowadays is usable, works well for 
>> simpler use cases and will be installed on every Debian system anyway).
>
>Last time I looked at it, systemd-networkd required several
>configuration files just to bring up a single interface. I can't say it
>was a very user-friendly experience. But perhaps things are better now?

I don't know when you have looked at systemd-networkd for the last
time, but ever since I looked at it, the trivial case just needs a
single file.

And the clear distinction between layers and interfaces is one of the
biggest advantages of systemd-networkd over ifupdown since it's
friendly to configuration management systems.

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

Re: ifupdown2: debconf followup

[Marc Haber]

On Mon, 1 Aug 2016 12:42:39 +0200, m...@linux.it (Marco d'Itri) wrote:
>On Aug 01, Adam Borowski  wrote:
>
>> > We should also think hard about switching to a new default since 
>> > currently many other major distributions are moving to NetworkManager 
>> > and/or systemd-networkd (which nowadays is usable, works well for 
>> > simpler use cases and will be installed on every Debian system anyway).
>> For the latter, "installable only with a certain init implementation, and
>> not portable to any kernel but Linux" doesn't say "every Debian system" to
>> me.
>Sorry, what I actually meant was "every non-toy Debian system".

Please at least try to be not this derogatory.

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

Re: [Pkg-sugar-devel] MBF: Removing old GNOME python bindings

[James Cameron]

On Mon, Aug 01, 2016 at 05:37:19PM +0200, Jonas Smedegaard wrote:
> Quoting Emilio Pozuelo Monfort (2016-08-01 16:43:06)
> > On 29/07/16 00:20, Jonas Smedegaard wrote:
> >> Quoting Emilio Pozuelo Monfort (2016-07-28 23:29:00)
> >>> It is high time that we remove the old GNOME python bindings. We 
> >>> have had the "new" GObject introspection support since at least 
> >>> Squeeze. The old ones are completely unmaintained and unsupported.
> >>>
> >>> I'd like to get gnome-python, gnome-python-extras, pyorbit, 
> >>> nautilus-python and pygtksourceview removed from testing for the 
> >>> Stretch release. Most of the gnome-python and gnome-python-extras 
> >>> binaries have already been removed. This is the final push.
> >>>
> >>> Removing pygtk and pygobject-2 may be unreasonable for Stretch, so 
> >>> if that can't happen we'll file bugs soon after the Stretch release 
> >>> (or file them earlier and bump the severity after the release) to 
> >>> get it done for Buster.
> >>>
> >>> For gnome-python{,-extras}, pyorbit, nautilus-python and 
> >>> pygtksourceview there are 54 reverse dependencies, and only 2 of 
> >>> them are key packages. One of those (cinnamon) doesn't actually need 
> >>> to depend on any of these packages and can just drop the dependency, 
> >>> and the other (hamster-applet) will need to be updated to a new 
> >>> upstream version or get removed as well.
> >> 
> >> The Sugar project is actively working towards migration from pygtk to 
> >> pygobject but is unlikely to finish that work before the freeze of 
> >> Stretch, unfortunately.
> >
> > I see that some of sugar has already been ported, e.g. 
> > sugar-toolkit-gtk3. Is there really no way things can be ported in 
> > time? These modules have been deprecated for years and we'd really 
> > like to get rid of them.
> 
> Sugar is an environment, where you can execute so-called "activities".  
> Hundreds of activities exist, where some of them is packaged for Debian.
> 
> Core Sugar components now uses python-sugar3 a.k.a. sugar-toolkit-gtk3, 
> but Sugar as an environment (called "Sucrose") is still defined as 
> including *both* the modern python-sugar3 *and* legacy python-sugar. 
> Many activities have not yet migrated yet, and Sugar without legacy 
> support will provide a severely broken Sugar experience.
> 
> 
> > Also, I wonder if we really need three versions of sugar.
> 
> I believe there is currently 2 (not 3) versions of Sugar in Debian.
> 
> 
> > The only remaining rdep for 0.88 seems to be sugar-moon-activity. That 
> > seems unmaintained: we have version 11 while upstream has 17, and the 
> > last maintainer activity was in 2010. Thus I have filed an RC bug on 
> > sugar-base-0.88 to get it out of Stretch.
> 
> Thanks.  I simply didn't take time to do that because it involved 
> packages maintained outside of the Sugar team (that Moon actitivy).
> 
> 
> > As for sugar-toolkit 0.98, there's only sugar-calculate-activity and 
> > sugar-presence-service (last upstream activity 2011, package 
> > description says it is deprecated) still depending on it. Maybe we 
> > should remove those as well so we can kill sugar 0.98?
> 
> No.  That package is part of legacy support in Sugar, it is discouraged 
> to develop any new activities based on that library, but there are 
> hundreds of Sugar activities still depending on it.

sugar-toolkit 0.109.0.2 was recently released upstream (10th July), so
packaging that would remove one appearance of lag.

> Yes, most of those activities are not in Debian - just as most of shell 
> scripts depending on Zsh is not in Debian, but it would still be a bad 
> idea to kick that package judging from its reverse dependencies (I 
> guess: I am not a Zsh user myself).
> 
> 
> > Getting those fixed or removed would mean that we don't have to ship 
> > multiple versions of sugar, and that we can get rid of the static 
> > GNOME python bindings.
> 
> Kicking Sugar 0.88 would indeed mean that we ship only a single version 
> of Sugar - but kicking python-sugar would cripple Sugar, just as I guess 
> kicking gtk2 would cripple GNOME.

Agreed.  If kicking gtk2 is a goal, that would have interesting
impacts.

> 
> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private



> -- 
> pkg-sugar-devel mailing list
> pkg-sugar-de...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-sugar-devel


-- 
James Cameron
http://quozl.netrek.org/

Re: [Pkg-sugar-devel] MBF: Removing old GNOME python bindings

[Emilio Pozuelo Monfort]

On 01/08/16 17:37, Jonas Smedegaard wrote:
> Yes, most of those activities are not in Debian - just as most of shell 
> scripts depending on Zsh is not in Debian, but it would still be a bad 
> idea to kick that package judging from its reverse dependencies (I 
> guess: I am not a Zsh user myself).

The difference is that zsh doesn't depend on and isn't blocking the removal of a
bunch of deprecated packages :P

There is software out there using all kinds of old libraries - yet we keep
removing old and unmaintained stuff from Debian.

Cheers,
Emilio

Re: ifupdown2: debconf followup

[Michael Biebl]

Am 01.08.2016 um 12:48 schrieb Guus Sliepen:
> I'd say a good starting point would be to try to switch the installer to
> configuring NetworkManager or systemd-networkd, instead of generating a
> /etc/network/interfaces file.

It already does that if the network-manager packages is installed by
d-i, say you install a GNOME desktop which pulls in NM as preferred
network configuration.
Then d-i will not create a config for ifupdown but NM.
This works since wheezy, IIRC.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: sybase license and openWatcom DFSGness

[Jakub Wilk]

* Guus Sliepen , 2016-08-01, 14:01:
Virtualbox is under GPL-2 with a lot of exception, allowing it to be 
used with MPL, Apache 2.0, OpenSSL.


So, LGPL-3 will be too restrictive I think for them.


It should be fine to combine GPL-2 and LGPL-3.


No, GPLv2 and LGPLv3 are not compatible:
https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

--
Jakub Wilk

Re: ifupdown2: debconf followup

[Roopa Prabhu]

On Mon, Aug 1, 2016 at 12:00 AM, Guus Sliepen  wrote:
> On Sun, Jul 31, 2016 at 06:58:20PM -0700, Roopa Prabhu wrote:
>
>> And, we will be very happy to work towards making ifupdown2
>> the default in Debian. If there are ways to make that happen, please let us 
>> know.
>
> First, try to make it compatible with 99% of the non-trivial
> ifupdown configurations.

agree 100%

> Why? First, everyone with a trivial network
> configuration (like auto eth0; iface eth0 inet dhcp) will not care
> about what network configuration tool brings up their network. The
> people have a more complex setup will care, and if you make it hard for
> them to move to ifupdown2, I think they'll rather stick with ifupdown.
> You either have to be able to parse ifupdown's /etc/network/interfaces
> or have a way to convert it to whatever new format ifupdown2 requires.

sure. We are backward compatible with ifupdown's interfaces file.
There are some limitations in areas of different address families other than
inet and inet6, but they can be fixed if found important. Most other
configuration
should work. We started with supporting complex network
configurations that were already deployed with ifupdown. And over the
years we have
added new styles and new formats to just make it easier to the user (while
trying to maintain backward compatibility).

>
> I see one big drawback of ifupdown2, and that is that it's written in
> Python. Nothing wrong with that language, but it means it pulls in
> dependencies which a minimal install currently doesn't require, which is
> not so nice for people running small VMs or embedded devices.

sure, this has been raised before. And we have been looking at a possibility
of shipping it as a self contained executable. perhaps by compiling
them into .pyc.

And, from my lessons learnt, a scripting language
is much more easier and extensible for network configurations.
We re-purpose and re-use a lot of already available components which would
not have been possible if we re-wrote it in C.


>
> If ifupdown2 is meant as a drop-in replacement for ifupdown, just fixing
> some bugs or adding a few missing features of ifupdown, I'd rather see
> those issues addressed in ifupdown. But of course, as one of the
> maintainers of ifupdown I'm quite biased :)

sure, we all are :).

For the complex network configurations that we support, it will
be difficult to fix ifupdown.

>
>> I also heard about some existing mailing list or discussions around solving 
>> ifupdown
>> problems. We would like to be part of those discussions to see
>> if ifupdown2 fits there.
>
> I don't know of such a mailing list... but there's always the BTS.
>

ok, thanks Guus

Re: [Pkg-sugar-devel] MBF: Removing old GNOME python bindings

[Jonas Smedegaard]

Quoting Emilio Pozuelo Monfort (2016-08-01 23:11:58)
> On 01/08/16 17:37, Jonas Smedegaard wrote:
>> Yes, most of those activities are not in Debian - just as most of 
>> shell scripts depending on Zsh is not in Debian, but it would still 
>> be a bad idea to kick that package judging from its reverse 
>> dependencies (I guess: I am not a Zsh user myself).
>
> The difference is that zsh doesn't depend on and isn't blocking the 
> removal of a bunch of deprecated packages :P
>
> There is software out there using all kinds of old libraries - yet we 
> keep removing old and unmaintained stuff from Debian.

Sometimes we do, sometimes we don't.  I bet you can find many cases of 
"old unmaintained stuff" e.g. in our TeX codebase.

What I think is appropriate to address is old, unmaintained and *broken* 
stuff.  Are python wrappers for GTK+ 2.x _broken_?

If the real issue here is that GNOME team no longer find the package 
relevant, then perhaps instead of removing pass over maintenance to 
others who do?


 - 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