Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

> You cannot have an MTA without configuring it, and nobody even tried to
> implement auto-migration of the old default mailer's configuration to the
> new one. Also, we didn't switch to a different default mailer because the
> new one offered a heap of features and infrastructure which the other
> lacked. None of this applies to systemd.

This does apply to systemd too.

When I got "upgraded" to systemd on july, my system was completely
misbehaving for several reasons related to my configuration:

- I had an ISO mount in my fstab, whose file didn't exist any more,
sysvinit never complained about it, systemd just stopped at boot.
- I had several bind mounts, forming loops, which has never been a
problem for sysvinit, but it made systemd take ages to boot & shutdown
because it'd crazily bring thousands of lines in /proc/mounts, details
in #755674.
- I had tweaks in /etc/inittab to get the gettys earlier than
daemon starts, in case those get stuck etc., this does not work any
more with systemd.
- I had tweaks in /etc/inittab to have more gettys on the text console,
this does not work with systemd any more.
- I had tweaks in /etc/inittab to shutdown instead of reboot when I
press ctrl-alt-backspace, this does not work with systemd any more.

If I had tweaks in /etc/inittab to enable serial consoles, would the
upgrade to systemd kept them working?  I haven't found code about this.
This is *especially* important for servers, for which that might be the
only way to access the system without having to take the bike to get to
the datacenter.

Of course, these are all bugs that could be fixed in systemd.  I however
doubt we can discover (and fix) them all for Jessie, and I strongly
doubt that the first item of my list (which is more a difference of
behavior than a bug) will be ever be fixed actually.

If it ain't broken, don't break it.

Samuel


-- 
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/20140909071103.ga2...@type.youpi.perso.aquilenet.fr

Bug#760915: ITP: cafeobj -- new generation algebraic specification and programming language

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 

* Package name: cafeobj
  Version : 1.5.0
  Upstream Author : Toshimi Sawada
* URL : http://www.cafeobj.org/
* License : BSD
  Programming Lang: Common Lisp
  Description : new generation algebraic specification and programming 
language

CafeOBJ is a most advanced formal specification language which 
inherits many advanced features (e.g. flexible mix-fix syntax,
powerful and clear typing system with ordered sorts, parameteric
modules and views for instantiating the parameters, and module
expressions, etc.) from OBJ (or more exactly OBJ3) algebraic
specification language.

CafeOBJ is a language for writing formal (i.e. mathematical) 
specifications of models for wide varieties of software and systems, 
and verifying properties of them. CafeOBJ implements equational logic
by rewriting and can be used as a powerful interactive theorem proving
system. Specifiers can write proof scores also in CafeOBJ and doing
proofs by executing the proof scores.

CafeOBJ has state-of-art rigorous logical semantics based on
nstitutions. The CafeOBJ cube shows the structure of the various
logics underlying the combination of the various paradigms implemented
by the language. Proof scores in CafeOBJ are also based on institution
based rigorous semantics, and can be constructed using a complete set 
of proof rules. 


-- 
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/20140909072134.19370.76843.reportbug@wienerschnitzel

Re: ok to ship vaporware in Debian?

[Fabian Greffrath]

Hello Jonas,

> In other words, mediaelement.js is a so-called polyfill - it does 
> nothing on modern browsers, and mimics modern features on older 
> browsers.

as far as I understand the mess, mediaelement.js provides an *API* for
media playback in browsers by acting as a wrapper around  and
 elements on modern browsers that supports them and by falling
back to its own Flash-/Silverlight-based implementation if not. As long
as it does the former properly (and I asume we do only ship "modern"
browsers in Debian nowadays) it does all that's needed, right?

- Fabian

PS: As an anecdote regarding "team maintenance", remember this one? 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630787



-- 
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/1410246554.6699.6.camel@kff50

Re: ok to ship vaporware in Debian?

[Andreas Henriksson]

Hello!

I see this as a question about main vs contrib.

Personally I'd put something like (libjs-)mediaelement in contrib
as obviously the main intended purpose it to use it together with
non-free software. But since it's not up to me

Policy says this about contrib:

"The contrib archive area contains supplemental packages intended to
work with the Debian distribution, but which require software outside of
the distribution to either build or function."

>From https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

So I guess the question becomes: can something that by designed
does nothing (without non-free software installed) be considered
functioning?

I guess your (Jonas) opinion is already clear on this by using the
vapourware term.

Regards,
Andreas Henriksson


-- 
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/20140909091124.ga4...@fatal.se

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> And you are saying that you can do all those tweaks, but you cannot
> pin systemd-sysv to not install?

No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
would have gotten all these changes all of a sudden without asking for
them. That can be pretty bad for the serial console access.

And I'm saying that I don't think this is an isolated case, I believe
most our users prefer to stay with sysvinit when upgrading from wheezy
to jessie, at least to keep the behavior of their machine as it is, and
then consider switching to systemd. Collapsing both is asking for
regressions and angry users (they already tell me bad Debian jokes about
the upgrade to systemd).

Samuel


-- 
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/20140909095444.gp3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> switch the default init to systemd as Debian
> maintainers who would like to keep their sanity would do.

I have lost my sanity about system boot & shutdown since when I have
switched to systemd. Really.

Samuel


-- 
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/20140909095640.gs3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 09:11, Samuel Thibault wrote:
> > You cannot have an MTA without configuring it, and nobody even tried to
> > implement auto-migration of the old default mailer's configuration to the
> > new one. Also, we didn't switch to a different default mailer because the
> > new one offered a heap of features and infrastructure which the other
> > lacked. None of this applies to systemd.
> 
> This does apply to systemd too.
> 
> When I got "upgraded" to systemd on july, my system was completely
> misbehaving for several reasons related to my configuration:
> 
> - I had an ISO mount in my fstab, whose file didn't exist any more,
> sysvinit never complained about it, systemd just stopped at boot.
> - I had several bind mounts, forming loops, which has never been a
> problem for sysvinit, but it made systemd take ages to boot & shutdown
> because it'd crazily bring thousands of lines in /proc/mounts, details
> in #755674.
> - I had tweaks in /etc/inittab to get the gettys earlier than
> daemon starts, in case those get stuck etc., this does not work any
> more with systemd.
> - I had tweaks in /etc/inittab to have more gettys on the text console,
> this does not work with systemd any more.
> - I had tweaks in /etc/inittab to shutdown instead of reboot when I
> press ctrl-alt-backspace, this does not work with systemd any more.

And you are saying that you can do all those tweaks, but you cannot
pin systemd-sysv to not install?

Let's just document the way how to prevent systemd-sysv to install
in release notes and switch the default init to systemd as Debian
maintainers who would like to keep their sanity would do.

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410256058.2294779.165322957.7f81e...@webmail.messagingengine.com

Re: More tasks option in Tasksel: what tasks do you want there?

[Andreas Tille]

Hi Cyril,

On Mon, Sep 08, 2014 at 02:33:06AM +0200, Cyril Brulebois wrote:
> 
> At some point it would really be nice to have a summary of what happened
> or what was discussed at DebConf, but on mailing lists. While I'm very
> happy to see stuff happen during in person meetings, keeping people who
> weren't there out of the loop shouldn't happen IMO.

+1
(specifically for people who did not joined DebConf)
 
> (I'm probably biased since I'm in that category; and maybe additionally
> slightly annoyed since I spent quite some time providing material for
> discussion with no feedback as of yet.)

Regarding one item of Adam's list the Blends topic you might like to
have a look at #758116 where we try to write down opinions.  Please note
that any of these Blends provide a *set* of tasks so it might make sense
if we have the space to add all seven listed Blends on the first screen
and enable to select single tasks after selecting one Blend (and perhaps
selecting more tasks from other Blends like for instance

Debian Med ---> select Biology

Debian Science ---> select tasks Statistics and Viewing

or something like this).

Kind regards and thanks for all your work for d-i

Andreas.


-- 
http://fam-tille.de


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

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 11:54, Samuel Thibault wrote:
> Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> > And you are saying that you can do all those tweaks, but you cannot
> > pin systemd-sysv to not install?
> 
> No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
> would have gotten all these changes all of a sudden without asking for
> them. That can be pretty bad for the serial console access.

Also broken libdb upgrade in hamm (I think) broke my system beyond
repair...  It's testing (and unstable), it's expected to have some
undocumented breakages. That's the sole reason to have the testing
and unstable in first place. To find the problems, fix them and if
that's
not possible (for various reasons[*]) then we should document that
in the release notes.

> And I'm saying that I don't think this is an isolated case,

And I'm saying that all we have is anecdotal evidence and we all
know what we step into when we run our systems on jessie or sid.
So please fill a bug for every breakage you will encounter, so it
can be either fixed or documented.

> I believe most our users prefer to stay with sysvinit when upgrading from 
> wheezy

And I believe that most our users don't care. But I as a maintainer
and operator of several daemons I really do care to have as most
unified environment for debugging the problems.

Ondrej
* - f.e. I am quite sure I broke some php5-cgi deployments by enforcing
the more strict security...
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410261048.2317496.165348985.0bb28...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 13:10:48 +0200, a écrit :
> On Tue, Sep 9, 2014, at 11:54, Samuel Thibault wrote:
> > Ondřej Surý, le Tue 09 Sep 2014 11:47:38 +0200, a écrit :
> > > And you are saying that you can do all those tweaks, but you cannot
> > > pin systemd-sysv to not install?
> > 
> > No, I'm saying that if I hadn't noticed "systemd" among the upgrades, I
> > would have gotten all these changes all of a sudden without asking for
> > them. That can be pretty bad for the serial console access.
> 
> Also broken libdb upgrade in hamm (I think) broke my system beyond
> repair...  It's testing (and unstable), it's expected to have some
> undocumented breakages. That's the sole reason to have the testing
> and unstable in first place. To find the problems, fix them and if
> that's
> not possible (for various reasons[*]) then we should document that
> in the release notes.

Sure. But I don't ever see us discovering all problems and fix them with
just the freeze period.

> > And I'm saying that I don't think this is an isolated case,
> 
> And I'm saying that all we have is anecdotal evidence and we all
> know what we step into when we run our systems on jessie or sid.
> So please fill a bug for every breakage you will encounter, so it
> can be either fixed or documented.

There will be dozens of them then. Will they really be fixed in time for
Jessie?

> > I believe most our users prefer to stay with sysvinit when upgrading from 
> > wheezy
> 
> And I believe that most our users don't care.

I believe most of our users care about an upgrade to Jessie that doesn't
bring regressions.

When we upgraded from grub1 to grub2, we have let the users decide when
they actually do the switch, so they can handle it independently from
the system upgrade. Why not doing the same here?

Samuel


-- 
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/20140909111931.gf3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Samuel Thibault, le Tue 09 Sep 2014 13:19:31 +0200, a écrit :
> > > I believe most our users prefer to stay with sysvinit when upgrading from 
> > > wheezy
> > 
> > And I believe that most our users don't care.
> 
> I believe most of our users care about an upgrade to Jessie that doesn't
> bring regressions.

It is also a matter of least surprise. Systemd behaves differently in a
fair amount of ways.

Samuel


-- 
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/20140909112323.gi3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 13:10, Ondřej Surý wrote:
>> > I believe most our users prefer to stay with sysvinit when upgrading from 
>> > wheezy
> And I believe that most our users don't care. But I as a maintainer
> and operator of several daemons I really do care to have as most
> unified environment for debugging the problems.

Most of our users don't care as long as their machines continue to work
as expected after an upgrade.

So, when upgrading from Wheezy to Jessie, we have three options:

1) Keep the user init system (sysvinit most probably)
2) Upgrade to systemd after asking the user.
3) Upgrade to systemd silently without asking the user.

I believe that the actual option (number 3) is going to cause much
breakage than the other alternatives.

Also, as I already expressed on bug #747535 this is not something I
would expect from Debian.

I expect Debian to be rock solid stable and to have painless upgrades
from one version to the next. The conservative (and safe) option is 1.

I understand that we want users to switch to systemd, so proper testing
is done and bugs are reported. So option 2 is a good compromise. By
asking users, each one can decide if he wants to risk to try systemd or not.

For example: I will try systemd on my laptop, but not on a remote server
that only is accessible via ssh.



signature.asc
Description: OpenPGP digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Matthias Urlichs]

Hi,

Samuel Thibault:
> > So please fill a bug for every breakage you will encounter, so it
> > can be either fixed or documented.
> 
> There will be dozens of them then. Will they really be fixed in time for
> Jessie?
> 
We don't know yet. Would you rather have bugs which are not even reported,
and operate from _really_ incomplete knowledge?

> When we upgraded from grub1 to grub2, we have let the users decide when
> they actually do the switch, so they can handle it independently from
> the system upgrade. Why not doing the same here?
> 
Nobody said that we wouldn't let the user decide. That's different from
what some people here seem to want, which is not do anything at all until
the admin explicitly installs systemd-sysv.

-- 
-- Matthias Urlichs


-- 
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/20140909114954.gq21...@smurf.noris.de

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 09/09/2014 13:10, Ondřej Surý wrote:
> And I'm saying that all we have is anecdotal evidence and we all
> know what we step into when we run our systems on jessie or sid.
> So please fill a bug for every breakage you will encounter, so it
> can be either fixed or documented.

Did you look at the current bug list for systemd ?
According to the PTS page, there are already 160 of them.

>> I believe most our users prefer to stay with sysvinit when upgrading from 
>> wheezy
> 
> And I believe that most our users don't care.

I agree, but if something breaks.

I consider myself having a not so bad level in system and
Linux administration. And I'm not able to fix the boot of my server.
I'm not even able to know exactly what is going wrong with it.
  Systemd have really interesting features, that why I'm testing it
and installing as much as I can. But the fact is that I not able
to deal with all the problems occurring when switching from sysv
on my own systems. So, I'm really confident that I wont be the only
one.

As others already tell, as much as possible, my opinion is that the
init switch should be done independently of the upgrade, and only
when explicitly requested by the administrator.
  The release note can emphasis that, for a better user experience,
the admin should really consider to do the switch of the init system
after the upgrade, for example by running
"apt-get install systemd-sysv" when the upgrade (and, if possible, a
reboot) is done.

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540eecf3.3090...@free.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Vincent Danjean]

On 09/09/2014 13:46, Carlos Alberto Lopez Perez wrote:
> So, when upgrading from Wheezy to Jessie, we have three options:
> 
> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.
[...]
> I understand that we want users to switch to systemd, so proper testing
> is done and bugs are reported. So option 2 is a good compromise. By
> asking users, each one can decide if he wants to risk to try systemd or not.

I agree with your analysis. However, how do you think we can ask
the user ? We can have a debconf question. However, whatever the answer
is, we must not return an error (i.e. aborting the upgrade). It is
really a pain to recover when this occurs.

> For example: I will try systemd on my laptop, but not on a remote server
> that only is accessible via ssh.

I agree with you.

  Regards,
Vincent.

-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540eee09.7090...@free.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Matthias Urlichs, le Tue 09 Sep 2014 13:49:54 +0200, a écrit :
> Samuel Thibault:
> > > So please fill a bug for every breakage you will encounter, so it
> > > can be either fixed or documented.
> > 
> > There will be dozens of them then. Will they really be fixed in time for
> > Jessie?
> > 
> We don't know yet. Would you rather have bugs which are not even reported,
> and operate from _really_ incomplete knowledge?

Well, I thought it was already well-known that quite a few regressions
are being brought, but apparently it's not. I'll just file bugs then.

> > When we upgraded from grub1 to grub2, we have let the users decide when
> > they actually do the switch, so they can handle it independently from
> > the system upgrade. Why not doing the same here?
> 
> Nobody said that we wouldn't let the user decide.
> That's different from what some people here seem to want, which is not
> do anything at all until the admin explicitly installs systemd-sysv.

No, I'm not asking this.  I'm asking not to upgrade to systemd silently.
Sure, people are supposed to read release notes.  But the release notes
can't mention all the differences of behavior brought by systemd that
may hurt the admin very badly (and far from everybody read release notes
unfortunately).

I have made a quick poll among various people here and there, there is
no real consensus, either on switching to systemd by default or keeping
with sysvinit by default. So it seems to me a question during upgrade is
needed.

Samuel


-- 
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/20140909121128.gr3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Samuel Thibault, le Tue 09 Sep 2014 14:11:28 +0200, a écrit :
> I have made a quick poll among various people here and there, there is
> no real consensus, either on switching to systemd by default or keeping
> with sysvinit by default. So it seems to me a question during upgrade is
> needed.

(more precisely, among 16 people, 5 for systemd, 9 for sysv, 2 don't
speak)

Samuel


-- 
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/20140909121651.gs3...@type.bordeaux.inria.fr

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Samuel Thibault]

Ondřej Surý, le Tue 09 Sep 2014 13:10:48 +0200, a écrit :
> > And I'm saying that I don't think this is an isolated case,
> 
> And I'm saying that all we have is anecdotal evidence

Our uni lab has switched to systemd, 20% of the machines do not boot.
The admin is currently looking at what the difference could be between
them to expain such a difference (same hardware, supposed-to-be same
software installation).

Samuel


-- 
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/20140909121931.gx3...@type.bordeaux.inria.fr

A life-changing book about truth

[Paul Smith]

Have you read the short book "The Present" yet? It's available free here.
Just go to the website: www.truthcontest.com

Click on the entry called The Present. What it says will turn this world
right-side up if it reaches enough people. You will see what I mean when
you read the first page.

Paul Smith

Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)

[Andreas Tille]

Hi Thomas,

thanks for caring for this topic.

On Mon, Sep 08, 2014 at 11:15:48PM +0800, Thomas Goirand wrote:
> ...
> So, with what you're proposing, we'll have something like this:
> 
>│[*] Desktop environment │
>│[*] ... Xfce│
>│[ ] ... GNOME   │
>│[ ] ... KDE │
>│[ ] Debian pure blends  │
>│[ ] ... Debian Edu  │
>│[ ] ... Debian Med  │
  [ ] ... Biology
  [ ] ... Medical imaging
  [ ] ... Medical practice
  ...
>│[ ] ... DebiChem│
  [ ] ... Ab inito
  [ ] ... Crystallography
  [ ] ... Molecular modelling
  ...
>│[ ] Openstack   │
>│[ ] ... Compute Node│
>│[ ] ... Proxy Node  │
> 
> This looks awesome already, a way better than what we had before.

+1

With the additional hint that Blends consists of a set of tasks which
usually can selected separately and in several (if not most) practical
cases it does not make sense to install them all at once.

Kind regards

   Andreas.

> [1] https://lists.debian.org/debian-boot/2014/09/msg00206.html
> [2] https://wiki.debian.org/tasksel/MoreTasks

-- 
http://fam-tille.de


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

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Mathieu Parent]

2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
[...]
> So, when upgrading from Wheezy to Jessie, we have three options:
>
> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.

4) Upgrade to systemd silently without asking the user AND add a grub
entry to use old init

This will provide the intended default with an extra compatibility
layer (like the former grub1 to grub2 chain).

Regards

-- 
Mathieu


-- 
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/CAFX5sbzQKq9AJ-L5NR8Vn2y=ZAk=vwphq8aimsn9i+k76l_...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Mathieu Parent]

2014-09-09 15:14 GMT+02:00 Mathieu Parent :
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
>> So, when upgrading from Wheezy to Jessie, we have three options:
>>
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
>
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

Oh. Michael Biebl already thought about it: #757298

Regards
-- 
Mathieu


-- 
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/CAFX5sbwLHCTnw8KXseERN8bO05U6VfPBgLKzdWX=gfmerem...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ondřej Surý]

On Tue, Sep 9, 2014, at 15:14, Mathieu Parent wrote:
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init

I like this approach very much since it's least intrusive to the upgrade
process, but provides a emergency fallback in default installation.

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1410272574.2370157.165422265.73c93...@webmail.messagingengine.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Samuel Thibault  writes:

> When I got "upgraded" to systemd on july, my system was completely
> misbehaving for several reasons related to my configuration:

> - I had an ISO mount in my fstab, whose file didn't exist any more,
> sysvinit never complained about it, systemd just stopped at boot.

Separate from the question of behavior on upgrades, I think we need to do
something about this before the jessie release.  There have been multiple
bug reports against openssh about its /run directory not being created
properly, which are due to this same issue.

Technically, those mounts need nofail if you don't care if they fail, but
sysvinit clearly never cared, so there are a lot of people out there with
failing mounts that they've just been ignoring.  When they install
systemd, the system then stops working in confusing ways.  I'm tempted to
say that installing systemd from a sysvinit system should mark anything
that isn't mounted at the time of the upgrade "nofail".

-- 
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/87oauou9j7@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Carlos Alberto Lopez Perez  writes:

> Most of our users don't care as long as their machines continue to work
> as expected after an upgrade.

> So, when upgrading from Wheezy to Jessie, we have three options:

> 1) Keep the user init system (sysvinit most probably)
> 2) Upgrade to systemd after asking the user.
> 3) Upgrade to systemd silently without asking the user.

> I believe that the actual option (number 3) is going to cause much
> breakage than the other alternatives.

> Also, as I already expressed on bug #747535 this is not something I
> would expect from Debian.

> I expect Debian to be rock solid stable and to have painless upgrades
> from one version to the next. The conservative (and safe) option is 1.

> I understand that we want users to switch to systemd, so proper testing
> is done and bugs are reported. So option 2 is a good compromise. By
> asking users, each one can decide if he wants to risk to try systemd or
> not.

+1

I don't believe we should switch init systems on upgrade without at least
a prompt, and given how easy it is to switch to systemd later, I think it
would be best to not switch init systems at all during an upgrade unless
forced to do so by other package dependencies (that may not happen at all
if systemd-shim is good enough).

We can prominantly document in the release notes how to switch to systemd
and encourage our users to do so, but there are enough differences in
behavior and enough conffiles that sysvinit honors and systemd doesn't
that I don't think we should just plow ahead without being clear about
what's going on.

-- 
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/87k35cu9ei@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Vincent Danjean  writes:

> I agree with your analysis. However, how do you think we can ask the
> user ? We can have a debconf question. However, whatever the answer is,
> we must not return an error (i.e. aborting the upgrade). It is really a
> pain to recover when this occurs.

The original plan was to have the question owned by some package that
could then switch the init symlink from one implementation to another.
That way, no abort is required.  I'm not sure if that survived contact
with reality, though, in the sense that I'm not sure how implementable it
is.

-- 
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/87d2b4u9ch@hope.eyrie.org

Bug#760968: ITP: libguasi -- Asynchronous syscall library

[Peter Pentchev]

Package: wnpp
Severity: wishlist
Owner: Peter Pentchev 

* Package name: libguasi
  Version : 0.25
  Upstream Author : Davide Libenzi 
* URL : http://xmailserver.org/guasi-lib.html
* License : LGPL-2.1+
  Programming Lang: C
  Description : Asynchronous syscall library

The guasi library implements a thread based generic asynchronous execution
engine, to be used to give otherwise synchronous calls an asynchronous
behaviour.  It can be used to wrap any synchronous call, so that it can be
scheduled for execution, and whose result can be fetched at later time
(hence not blocking the submitter thread).  The guasi library can be used
as complement to standard event retrieval interfaces like poll(2),
select(2) or epoll(4).  The guasi library is generic, meaning that any
otherwise synchronous function (not only system calls) can be made
asynchronous.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: Digital signature

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ansgar Burchardt]

On 09/09/2014 16:59, Russ Allbery wrote:
> Carlos Alberto Lopez Perez  writes:
>> So, when upgrading from Wheezy to Jessie, we have three options:
> 
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
[...]
>> I understand that we want users to switch to systemd, so proper testing
>> is done and bugs are reported. So option 2 is a good compromise. By
>> asking users, each one can decide if he wants to risk to try systemd or
>> not.
> 
> +1
> 
> I don't believe we should switch init systems on upgrade without at least
> a prompt, and given how easy it is to switch to systemd later, I think it
> would be best to not switch init systems at all during an upgrade unless
> forced to do so by other package dependencies (that may not happen at all
> if systemd-shim is good enough).

I think there are good arguments for both switching to the new default
and not: on one hand the migration will fail in some cases (and I doubt
we will find all of them), on the other hand I believe we want most
users to switch to the default init system, at least mid to long term.
Being the default means it will be better tested and provide a better
experience to (most) users.

We could delay the transition-on-upgrade by one release, but the
migration from sysvinit to systemd on a Jessie -> Jessie+1 upgrade will
probably end up less tested (though systemd itself would probably be
more tested by then).

Having only some systems switch to a different init system on upgrade
seems potentially confusing to me. That said, it would be nice if
systemd-sysv could check for common problems on installation and issue a
debconf warning, e.g. when not currently mounted entries are present in
/etc/fstab or when keyscripts for cryptsetup are used.

Ansgar


-- 
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/540f19af.3010...@debian.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ansgar Burchardt]

On 09/09/2014 17:01, Russ Allbery wrote:
> Vincent Danjean  writes:
>> I agree with your analysis. However, how do you think we can ask the
>> user ? We can have a debconf question. However, whatever the answer is,
>> we must not return an error (i.e. aborting the upgrade). It is really a
>> pain to recover when this occurs.
> 
> The original plan was to have the question owned by some package that
> could then switch the init symlink from one implementation to another.
> That way, no abort is required.  I'm not sure if that survived contact
> with reality, though, in the sense that I'm not sure how implementable it
> is.

The different init systems would have to be co-installable for this to
work, however they are not.

For the planned fallback in grub to offer sysvinit on systemd systems, a
second copy of sysvinit's /sbin/init was included in a non-conflicting
package in a different location, but systemd's implementation of halt,
poweroff, ... would still be used (as these work with sysvinit's init as
well).

Ansgar


-- 
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/540f1a90.6050...@debian.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Russ Allbery]

Ansgar Burchardt  writes:
> On 09/09/2014 17:01, Russ Allbery wrote:

>> The original plan was to have the question owned by some package that
>> could then switch the init symlink from one implementation to another.
>> That way, no abort is required.  I'm not sure if that survived contact
>> with reality, though, in the sense that I'm not sure how implementable
>> it is.

> The different init systems would have to be co-installable for this to
> work, however they are not.

They used to be.  Did we lose this somehow?

Oh, right, I remember the problem with this.  It was that various packages
required that systemd not only be installed but be running (for logind
reasons), and a dependency that can be satisfied by either init system
wasn't sufficient for this.  So you actually need systemd-shim to be
co-installable with systemd.  But I think that's now the case again,
correct?  In which case we could explore this again.

-- 
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/87iokwyfey@hope.eyrie.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Michael Biebl]

Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> Having only some systems switch to a different init system on upgrade
> seems potentially confusing to me.

Agreed. We definitely should switch the machines on upgrades. There is a
good reason why we also did it when switching to dependency based boot.

 That said, it would be nice if
> systemd-sysv could check for common problems on installation and issue a
> debconf warning, e.g. when not currently mounted entries are present in
> /etc/fstab or when keyscripts for cryptsetup are used.

Nod. I'm planning to add such checks to systemd-sysv preinst (I think we
already have a bug report open for that).

If it finds such issues on first installation, it will pop up a debconf
prompt displaying the issues it found with some hints how to fix them
and the choice to abort or continue with the installation.

Together with the /lib/sysvinit/init fallback binary in sysvinit and
(and optionally my patch getting merged for grub [1]), this should
provide for a hopefully seamless upgrade experience.


Michael


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757298
-- 
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

Summary from the d-i / debian-cd BoF at DC14

[Steve McIntyre]

[ Please note the cross-post and Reply-To ]

Hi folks,

As promised, here's a quick summary of what was discussed at the BoF
session in Portland. Apologies for the delay - it takes a while to
write these up... :-/

Thanks to the awesome efforts of our video team, the session is
already online [1].  I've taken a copy of the (partial!) Gobby notes
too, alongside my small set of slides for the session. [2]

Current D-I Status
==

Jessie D-I Beta 1 released recently. Some known issues and regressions
documented already, but please help test the images we already have -
particularly on the less common architectures, languages, installer
options. We're worried particularly about some of the architectures
where bugs are showing up that suggest people are not using/testing
the installer very often - kfreebsd ports are a worry here, for
example.

Release scheduling has been an issue for a very long time. We've
spoken about maybe switching to a regular cycle for d-i releases
(monthly/2-monthly?) since forever, but we're still not there
yet. Would be lovely to release and migrate using the normal testing
setup, but we've never got there yet. Short on manpower - testing,
fixing bugs, etc.

D-I Plans
=

* Switching to the graphical installer by default for Jessie, where it
  makes sense (i.e. on x86 systems). As discussed 2/3/4 years
  ago. It's not just to make things prettier, the graphical installer
  is the only option for certain languages / writing systems that
  cannot be supported in the text installer.

* Default desktop discussion has come up again. Joey has plans to work
  out the best default desktop choice, similarly to how the release
  architectures are chosen. New wiki page [3] added to help track
  this, and another BoF organised later in the week at DebConf [4,5] to
  go into this in more detail. 

* Desktop choice - Frans Pop added syslinux years back to allow choice
  of desktop at install time because tasksel didn't. Time to revisit
  that. Discussion about adding more/different options to tasksel. The
  Blends folks (and others) would like some of their tasks to be
  included too. Maybe add an extra *limited* set of options to
  tasksel, more discussion later. Translations could be an issue if we
  want to get big changes like this in for Jessie release - don't
  leave it too long!

* Do we *need* a default desktop? YES - many typical users won't know
  what the different desktop options are, and often won't care. They
  just want to download Debian and install it, and we need to make a
  sensible default choice for those people.

* Jessie artwork - paultag is organising this, so far. Still quite a
  bit of work to do once we have chosen the right artwork, which will
  take time.

* Lots of bug fixes to come in d-i yet, e.g. firmware support

* New architectures will want supporting in the installer: arm64 and
  ppc64el. d-i should be working very soon on those architectures if
  not already.

* UEFI Secure Boot has been missing manpower so far, which is why it's
  not happened so far. Another session later in the week with more
  details [6]. Needs some work from DSA, ftp team, grub, kernel, d-i,
  debian-cd teams. Might make it for Jessie?

* Graphical installer is still using gtk2; porting to gtk3 is unlikely
  for Jessie at this point without help doing that.

Help!
=

Please!

* We can't test all the architectures/code paths ourselves - please
  help *now* before it's too late for the Jessie release.

* OpenSUSE have a magic installer test framework that may help us here
  - if somebody could take a look that would be awesome - it might be
  very helpful.

* Bug-handling is another area - as we get more installation reports
  for Jessie. we'll need help to evaluate those and file more detailed
  bug reports about particular failures. KiBi can't do all this on his
  own!

* More stuff - translations (Christian and team!), bug fixes, etc.

* New stuff. d-i is great and mostly stable and works for most people,
  but there will always be more cool things we can/could do if only we
  had the time to do them.

Debian-CD Status


We're still building massive sets of images every day and every
week. Things are mostly working, clearly!

For the last couple of Wheezy point releases, we've been building the
debian-live images on our standard central CD build machine
(pettersson) alongside the regular installer images, built and signed
by Steve. Daniel's work on debian-live is awesome, but there have been
issues in the past co-ordinating times to do releases together.

Debian-CD Plans
===

* Which images do we want to make for Jessie? Currently we have, for
  every architecture:
  + netinst
  + CD set
  + alternate versions of CD#1 for each of the desktops (gnome/kde/xfce/lxde)
  + DVD
  + BD (x86 only)

  We're ready and able to add more CD options for other desktops too,
  as soon as they have appropriate tasks ready for tasksel. Recently
  fixed 

Seeking help with OpenVPN scripts and systemd

[Alberto Gonzalez Iniesta]

AltSubject: For those who care about OpenVPN

Dear fellow developers,

This is a cry for help. I've been trying to support systemd in OpenVPN for some
time, but the results are not satisfactory. I'd like to keep the current (SysV)
behaviour in systemd but it's becoming quite an annoying task.

I'd love to hear recommendations, receive patches or any other help with this.
Let me explain what the SysV init script did, so you can figure out what I'd
like to achieve. If you aren't interested in the task you may skip the rest of
this mail.

What was working?
-

First of all, openvpn in Debian is able to run several VPN daemons. Depending
on the value of the configuration variable AUTOSTART (in /etc/default/openvpn):
- all -> A daemon for each of the configuration files found in /etc/openvpn
- none -> Do not manage any VPN (they can be started manually or through a
  directive in /etc/network/interfaces
- A list of the VPNs you want automatically managed (i.e. AUTOSTART="work
  home"). The rest can be managed manually.

In order to be able to control individual VPNs the init.d script accepts a
second argument (after start/stop/...) with the name of the VPN to manage. I
know this was a hack, but it worked like a charm. This is no longer possible
with systemd.

stop, reload, soft-restart and cond-restart will only affect running VPNs.
The last one is specially important in upgrades, when the currently running
daemons have to restart. That includes those VPNs that are managed
automatically (in AUTOSTART) *and* those started manually or through a
network/interfaces directive. Whereas restart will only affect those managed
automatically unless a VPN name is specified.

In addition to the init.d script, there are two script in
/etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when
interfaces are brought up or down. So you may have AUTOSTART=none, or
AUTOSTART="home office", and then enable "work" tunnel when only when using a
specific network interface.

Where are we now?
-

The latest version of openvpn's package (in experimental) includes two service
files for systemd. One instantiated (openvpn@.service) allows the control of
single VPNs, piece of cake.

The main issue is with the other one, openvpn.service, that tries to replace
the old init.d script and all its features. It is, currently, calling a helper
script that (tries to) mimic(s) the former behaviour.

First of all, the script can only be called with start, stop or reload
arguments. So no distinction can be made between a restart and a
stop-then-start. So there's no way (i.e.  on an upgrade) to restart all VPNs
(those in AUTOSTART *and* those manually controlled), since "start" and "stop"
should only manage those in AUTOSTART.

Another problem is the package upgrade to systemd in a running system, since
the VPNs started with the current init.d script are not recognized by
openvpn@NAME.service. So when upgrading the package from the
non-systemd-enabled package (< 2.3.2-7) to the package with the service files,
we end up with two active VPNs (the one that was running, and one started by
systemd) for each AUTOSTARTed configuration.

If you know systemd and would like to help with this please Cc: me (since I'm
not subscribed to -devel) or mail me directly. You may find the current git
repo for openvpn in Debian at: git.debian.org/git/collab-maint/openvpn.git

Thanks,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55


-- 
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/20140909155120.ga18...@bin.inittab.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 15:14, Mathieu Parent wrote:
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
>> So, when upgrading from Wheezy to Jessie, we have three options:
>>
>> 1) Keep the user init system (sysvinit most probably)
>> 2) Upgrade to systemd after asking the user.
>> 3) Upgrade to systemd silently without asking the user.
> 
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init
> 
> This will provide the intended default with an extra compatibility
> layer (like the former grub1 to grub2 chain).
> 

This may be a good option when you have pre-boot access to the machine
(either physical access or with a KVM), so you can select an option on
the GRUB menu if things go wrong.

But if you don't (Is not uncommon to have servers on remote locations
that are only accessible via ssh) and the machine don't boots properly
you can find yourself in trouble.

When the transition to GRUB2 was made, it didn't replaced the previous
system (GRUB1) without asking the user. What it did was to add a new
(non default) entry on GRUB1 to chainload to GRUB2. The idea was that
the user could test the new system when he felt it was a good moment.
So, after checking that all worked as expected, he could make the new
system the default by executing a command: upgrade-from-grub-legacy. [1]


I wish something similar would be made for the switch to systemd:

1. Add a new entry on GRUB to boot with systemd (but leave the previous
init system as default).
2. Add a command upgrade-from-init-legacy or upgrade-to-systemd that
sets the option to boot with systemd as default.

That way the user can test to boot with systemd when he feels like is a
good moment, and if things work as expected he can make the switch
definitively by executing that command.





[1] https://wiki.debian.org/Grub#Upgrading_from_v1_to_v2



signature.asc
Description: OpenPGP digital signature

The developers of Debian Linux think there was no point in coding in binary code three years ago as they did or make the Riga Technical University and University of Latvia?

[françai s]

Members of forum, especially the ReactOS developers, I could not
resist the urge to now post the following message:

This message is mainly for developers of ReactOS operating system.

What are the programming languages ​​that were used to develop the
Debian Linux ?

Probably the Riga Technical University and University of Latvia
continue teaching coding in binary code, in other words, machine language.

I say this because about three years ago the Riga Technical University
and University of Latvia continued teaching coding in binary code, in
other words ,
machine language.

The Riga Technical University and University of Latvia made ​​based
projects in Debian Linux using coding in binary code?

The developers of Debian Linux think there was no point in coding in binary
code three years ago as they did or make the Riga Technical University
and University of Latvia?


--
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/CAK_6RwfG9HpaExui_CAqvp=zDre_e3mK+4k1ib9n3z=en2z...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Ansgar Burchardt  [140909 11:16]:
> On 09/09/2014 16:59, Russ Allbery wrote:
> > I don't believe we should switch init systems on upgrade without at least
> > a prompt,
> 
> I think there are good arguments for both switching to the new default
> and not:

Perhaps, but not without giving the sysadmin a choice, unless you have
handled all the cases where the sysadmin has modified configuration
files such as /etc/inittab and scripts in /etc/init.d.

...Marvin


-- 
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/20140909190423.gc3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Mathieu Parent  [140909 09:15]:
> 2014-09-09 13:46 GMT+02:00 Carlos Alberto Lopez Perez :
> [...]
> > So, when upgrading from Wheezy to Jessie, we have three options:
> >
> > 1) Keep the user init system (sysvinit most probably)
> > 2) Upgrade to systemd after asking the user.
> > 3) Upgrade to systemd silently without asking the user.
> 
> 4) Upgrade to systemd silently without asking the user AND add a grub
> entry to use old init
> 
> This will provide the intended default with an extra compatibility
> layer (like the former grub1 to grub2 chain).

Debian packages at least two other families of boot loaders.  I am using
syslinux-efi on one machine, and have used lilo and elilo in the past.
Adding a grub entry will not adequately solve the problem.

...Marvin


-- 
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/20140909185819.gb3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Marvin Renich]

* Michael Biebl  [140909 11:43]:
> Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> > Having only some systems switch to a different init system on upgrade
> > seems potentially confusing to me.
> 
> Agreed. We definitely should switch the machines on upgrades. There is a
> good reason why we also did it when switching to dependency based boot.

I disagree.  Switching automatically might be okay if the sysadmin has
not made any local modifications to the boot process, or if you can be
sure that systemd is going to do the right thing with the sysadmin's
modifications, but preserving local sysadmin changes has alway been one
of the things that set Debian apart from other distros.  Please don't
mess this up now.

As for dependency based boot, it recognized when it could not handle it
properly (at least on one machine of mine) and fell back to manual
ordering, with an appropriate log message.  ISTR that I had two full
releases after upgrading to dependency based boot before I was forced to
fix it.  If systemd gives that kind of fallback, I will not complain.

...Marvin


-- 
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/20140909191638.gd3...@basil.wdw

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

> But if you don't (Is not uncommon to have servers on remote locations
> that are only accessible via ssh) and the machine don't boots properly
> you can find yourself in trouble.

Then surely you test the upgrade before making it live, using kvm
-snapshot or similar functionality?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2wq9c1r9s@rahvafeir.err.no

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Noel Torres]

On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> ]] Carlos Alberto Lopez Perez
> 
> > But if you don't (Is not uncommon to have servers on remote locations
> > that are only accessible via ssh) and the machine don't boots properly
> > you can find yourself in trouble.
> 
> Then surely you test the upgrade before making it live, using kvm
> -snapshot or similar functionality?

This is simply not possible in physical live, productions servers on remote 
CPDs.

Regards


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

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 22:18, Tollef Fog Heen wrote:
> ]] Carlos Alberto Lopez Perez 
> 
>> But if you don't (Is not uncommon to have servers on remote locations
>> that are only accessible via ssh) and the machine don't boots properly
>> you can find yourself in trouble.
> 
> Then surely you test the upgrade before making it live, using kvm
> -snapshot or similar functionality?
> 

That way of testing is completely unreliable when we are talking about
low level stuff (kernel/udev/systemd).

I'm talking about physical (bare-metal) servers. Testing the upgrade on
a virtual machine does not help since the behavior of the system is
hardware dependent, and kvm can't reproduce that.

In any case, I'm not worried by the servers I manage. I know the current
status quo is to replace sysvinit with systemd on upgrades without
telling the user. So I'm ready to pin sysvinit if I think is a wiser choice.

What I'm trying to improve is the experience of the Debian users that
won't know that, and will upgrade their servers from Wheezy to Jessie.

I truly believe that making systemd the default without asking the user
to test it first, is going to cause more breakage and angry users than
doing it the other way.



signature.asc
Description: OpenPGP digital signature

Re: Seeking help with OpenVPN scripts and systemd

[Noel Torres]

On Tuesday, 9 de September de 2014 16:51:20 Alberto Gonzalez Iniesta escribió:
> AltSubject: For those who care about OpenVPN
> 
> Dear fellow developers,
> 
> This is a cry for help. I've been trying to support systemd in OpenVPN for
> some time, but the results are not satisfactory. I'd like to keep the
> current (SysV) behaviour in systemd but it's becoming quite an annoying
> task.
> 
> I'd love to hear recommendations, receive patches or any other help with
> this. Let me explain what the SysV init script did, so you can figure out
> what I'd like to achieve. If you aren't interested in the task you may
> skip the rest of this mail.
> 
> What was working?
> -
> 
> First of all, openvpn in Debian is able to run several VPN daemons.
> Depending on the value of the configuration variable AUTOSTART (in
> /etc/default/openvpn): - all -> A daemon for each of the configuration
> files found in /etc/openvpn - none -> Do not manage any VPN (they can be
> started manually or through a directive in /etc/network/interfaces
> - A list of the VPNs you want automatically managed (i.e. AUTOSTART="work
>   home"). The rest can be managed manually.
> 
> In order to be able to control individual VPNs the init.d script accepts a
> second argument (after start/stop/...) with the name of the VPN to manage.
> I know this was a hack, but it worked like a charm. This is no longer
> possible with systemd.
> 
> stop, reload, soft-restart and cond-restart will only affect running VPNs.
> The last one is specially important in upgrades, when the currently running
> daemons have to restart. That includes those VPNs that are managed
> automatically (in AUTOSTART) *and* those started manually or through a
> network/interfaces directive. Whereas restart will only affect those
> managed automatically unless a VPN name is specified.
> 
> In addition to the init.d script, there are two script in
> /etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when
> interfaces are brought up or down. So you may have AUTOSTART=none, or
> AUTOSTART="home office", and then enable "work" tunnel when only when using
> a specific network interface.
> 
> Where are we now?
> -
> 
> The latest version of openvpn's package (in experimental) includes two
> service files for systemd. One instantiated (openvpn@.service) allows the
> control of single VPNs, piece of cake.
> 
> The main issue is with the other one, openvpn.service, that tries to
> replace the old init.d script and all its features. It is, currently,
> calling a helper script that (tries to) mimic(s) the former behaviour.
> 
> First of all, the script can only be called with start, stop or reload
> arguments. So no distinction can be made between a restart and a
> stop-then-start. So there's no way (i.e.  on an upgrade) to restart all
> VPNs (those in AUTOSTART *and* those manually controlled), since "start"
> and "stop" should only manage those in AUTOSTART.
> 
> Another problem is the package upgrade to systemd in a running system,
> since the VPNs started with the current init.d script are not recognized
> by openvpn@NAME.service. So when upgrading the package from the
> non-systemd-enabled package (< 2.3.2-7) to the package with the service
> files, we end up with two active VPNs (the one that was running, and one
> started by systemd) for each AUTOSTARTed configuration.
> 
> If you know systemd and would like to help with this please Cc: me (since
> I'm not subscribed to -devel) or mail me directly. You may find the
> current git repo for openvpn in Debian at:
> git.debian.org/git/collab-maint/openvpn.git
> 
> Thanks,
> 
> Alberto

Hi Alberto

openvpn package should Conflitcs systemd in order to avoid systemd being 
installed and so messing with OpenVPN-working systems, until systemd gets 
appropiately fixed or you get a workaround.

Regards

er Envite


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

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 22:34, Carlos Alberto Lopez Perez wrote:
> I truly believe that making systemd the default without asking the user
> to test it first, is going to cause more breakage and angry users than
> doing it the other way.

s/making systemd the default/replacing the user init system with systemd on 
upgrades/



signature.asc
Description: OpenPGP digital signature

Re: Seeking help with OpenVPN scripts and systemd

[Patrick Matthäi]

Von meinem iPad gesendet

> Am 09.09.2014 um 22:26 schrieb Noel Torres :
> 
> On Tuesday, 9 de September de 2014 16:51:20 Alberto Gonzalez Iniesta escribió:
>> AltSubject: For those who care about OpenVPN
>> 
>> Dear fellow developers,
>> 
>> This is a cry for help. I've been trying to support systemd in OpenVPN for
>> some time, but the results are not satisfactory. I'd like to keep the
>> current (SysV) behaviour in systemd but it's becoming quite an annoying
>> task.
>> 
>> I'd love to hear recommendations, receive patches or any other help with
>> this. Let me explain what the SysV init script did, so you can figure out
>> what I'd like to achieve. If you aren't interested in the task you may
>> skip the rest of this mail.
>> 
>> What was working?
>> -
>> 
>> First of all, openvpn in Debian is able to run several VPN daemons.
>> Depending on the value of the configuration variable AUTOSTART (in
>> /etc/default/openvpn): - all -> A daemon for each of the configuration
>> files found in /etc/openvpn - none -> Do not manage any VPN (they can be
>> started manually or through a directive in /etc/network/interfaces
>> - A list of the VPNs you want automatically managed (i.e. AUTOSTART="work
>>  home"). The rest can be managed manually.
>> 
>> In order to be able to control individual VPNs the init.d script accepts a
>> second argument (after start/stop/...) with the name of the VPN to manage.
>> I know this was a hack, but it worked like a charm. This is no longer
>> possible with systemd.
>> 
>> stop, reload, soft-restart and cond-restart will only affect running VPNs.
>> The last one is specially important in upgrades, when the currently running
>> daemons have to restart. That includes those VPNs that are managed
>> automatically (in AUTOSTART) *and* those started manually or through a
>> network/interfaces directive. Whereas restart will only affect those
>> managed automatically unless a VPN name is specified.
>> 
>> In addition to the init.d script, there are two script in
>> /etc/network/if-(up|down).d/openvpn that allow for VPNs to be managed when
>> interfaces are brought up or down. So you may have AUTOSTART=none, or
>> AUTOSTART="home office", and then enable "work" tunnel when only when using
>> a specific network interface.
>> 
>> Where are we now?
>> -
>> 
>> The latest version of openvpn's package (in experimental) includes two
>> service files for systemd. One instantiated (openvpn@.service) allows the
>> control of single VPNs, piece of cake.
>> 
>> The main issue is with the other one, openvpn.service, that tries to
>> replace the old init.d script and all its features. It is, currently,
>> calling a helper script that (tries to) mimic(s) the former behaviour.
>> 
>> First of all, the script can only be called with start, stop or reload
>> arguments. So no distinction can be made between a restart and a
>> stop-then-start. So there's no way (i.e.  on an upgrade) to restart all
>> VPNs (those in AUTOSTART *and* those manually controlled), since "start"
>> and "stop" should only manage those in AUTOSTART.
>> 
>> Another problem is the package upgrade to systemd in a running system,
>> since the VPNs started with the current init.d script are not recognized
>> by openvpn@NAME.service. So when upgrading the package from the
>> non-systemd-enabled package (< 2.3.2-7) to the package with the service
>> files, we end up with two active VPNs (the one that was running, and one
>> started by systemd) for each AUTOSTARTed configuration.
>> 
>> If you know systemd and would like to help with this please Cc: me (since
>> I'm not subscribed to -devel) or mail me directly. You may find the
>> current git repo for openvpn in Debian at:
>> git.debian.org/git/collab-maint/openvpn.git
>> 
>> Thanks,
>> 
>> Alberto
> 
> Hi Alberto
> 
> openvpn package should Conflitcs systemd in order to avoid systemd being 
> installed and so messing with OpenVPN-working systems, until systemd gets 
> appropiately fixed or you get a workaround.

Please troll elsewhere. The upcoming Debian Release will come with systemd and 
it is not helpful at all if trolls just trolling around on serious user 
questions.

--
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/e2283334-3ba5-47be-9bba-3a81f14ae...@debian.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Tollef Fog Heen]

]] Carlos Alberto Lopez Perez 

> On 09/09/14 22:18, Tollef Fog Heen wrote:
> > ]] Carlos Alberto Lopez Perez 
> > 
> >> But if you don't (Is not uncommon to have servers on remote locations
> >> that are only accessible via ssh) and the machine don't boots properly
> >> you can find yourself in trouble.
> > 
> > Then surely you test the upgrade before making it live, using kvm
> > -snapshot or similar functionality?
> > 
> 
> That way of testing is completely unreliable when we are talking about
> low level stuff (kernel/udev/systemd).

No, it's not.  It is able to emulate most of the concerns people are
talking about in this thread.  Nobody has so far showed up and been
worried about udev suddenly being incompatible, from what I've seen it's
all about worries that things like buggy /etc/fstabs and similar
problems prevent a clean boot.

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3zksdd2@xoog.err.no

Bug#761015: ITP: piglit -- Piglit OpenGL test suite

[Jordan Justen]

Package: wnpp
Severity: wishlist
Owner: Jordan Justen 

* Package name: piglit
  Version : 0.0.0
  Upstream Author : Piglit 
* URL : http://piglit.freedesktop.org/
* License : MIT, GPL
  Programming Lang: C, C++, Python
  Description : Piglit OpenGL test suite

Piglit is an open-source test suite for OpenGL implementations.

Piglit is used extensively for testing of the open source Mesa
project.

Piglit has not previously done any official project releases. This is
why I set the version at 0.0.0. The piglit builds will use a version
of the form
  0.0.0~git[8 digit date]-[7 hex git sha1 prefix]-[debian version]

I plan to maintain debian piglit myself, although there are a few
Debian Developers that are also work on piglit which may end up
helping to maintain it. I plan to work with Carl Worth
 to sponsor/upload the piglit packages.


-- 
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/20140909213304.7149.80641.reportbug@localhost

Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)

[Markus Koschany]

On 09.09.2014 00:19, Paul Wise wrote:
> On Tue, Sep 9, 2014 at 12:57 AM, Rebecca Palmer wrote:
>>> Someone already
>>> proposed, in the wiki, to add "Games". I like the idea a lot, and it
>>> perfectly makes sense to select all games at once.
> 
> That was me. We don't yet have a games-all metapackage in the games
> blend, games-finest is probably a good alternative for now.

Creating a games-all metapackage would be easily doable but I wonder if
there was a more elegant way to solve this problem and if we could avoid
the creation of "meta-metapackages". I could imagine another check box
in tasksel for instance. If checked all separate installable games-*
tasks for users would be selected and all tasks for developers and
artists, the -dev packages, would be excluded.

>> You might want to check the download size it would have first: some game
>> data packages are _big_ (~1GB for flightgear, ~400MB each for openarena and
>> wesnoth, ~7.5GB total for the games-finest collection).
> 
> Good point, tasksel needs some indicator of sizes.

Indeed that would be a neat feature. In the meantime you might also want
to try »games-finest-light« which installs smaller and less hardware
demanding games although it's still ~2.5GB.

Markus





signature.asc
Description: OpenPGP digital signature

Re: ok to ship vaporware in Debian?

[Dimitri John Ledkov]

Heya,

On 8 September 2014 21:38, Jonas Smedegaard  wrote:
>
> ...except it really does nothing when that mimic'ing code is missing.
>

I've seen multiple times where a "framework" with a "plugin"
architecture was meant to provide "unified API", but in practice none
of the plugins were packaged/installed/usable and thus the "unified
API" was just a layer of abstraction / indirection with no added
value. Path of least resistance is to package this and go on with
doing better things. Ideally one would patch that out, and e.g. make
things that depend on that js library to just use straight html5
tags/api/etc.

-- 
Regards,

Dimitri.


-- 
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/canbhluj_vu-voqnb3azcwqohq6b2tymnkhlb+fsr+uivuzt...@mail.gmail.com

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Carlos Alberto Lopez Perez]

On 09/09/14 23:17, Tollef Fog Heen wrote:
>> That way of testing is completely unreliable when we are talking about
>> > low level stuff (kernel/udev/systemd).
> No, it's not.  It is able to emulate most of the concerns people are
> talking about in this thread.  Nobody has so far showed up and been
> worried about udev suddenly being incompatible, from what I've seen it's
> all about worries that things like buggy /etc/fstabs and similar
> problems prevent a clean boot.

I just gave a quick look at the list of systemd open bugs on the BTS
that can cause an unbootable system. At least #697962, #627949, #751585,
#754078 and #760848 are very difficult (if not impossible) to test
properly with the testing method you are proposing.



signature.asc
Description: OpenPGP digital signature

Re: The developers of Debian Linux think there was no point in coding in binary code three years ago as they did or make the Riga Technical University and University of Latvia?

[Gunnar Wolf]

françai s dijo [Tue, Sep 09, 2014 at 03:17:00PM -0300]:
> Members of forum, especially the ReactOS developers, I could not
> resist the urge to now post the following message:
> 
> This message is mainly for developers of ReactOS operating system.

Umh, I'm sorry, this is Debian-land, you will not find many ReactOS
people here.

> What are the programming languages ​​that were used to develop the
> Debian Linux ?

Practically any and every language you can think of. Debian is not
just Linux (Linux is mostly written in C, with bits of assembler), but
a set of literally tens of thousands of other projects.

> Probably the Riga Technical University and University of Latvia
> continue teaching coding in binary code, in other words, machine language.
> 
> I say this because about three years ago the Riga Technical
> University and University of Latvia continued teaching coding in
> binary code, in other words , machine language.
> 
> The Riga Technical University and University of Latvia made ​​based
> projects in Debian Linux using coding in binary code?
> 
> The developers of Debian Linux think there was no point in coding in binary
> code three years ago as they did or make the Riga Technical University
> and University of Latvia?

[Let me put my teacher hat on]

Let me correct a bit your point here: I can *assure* you the
University of Latvia didn't ever teach to code either in binary code
or in machine language. In any case, they might have taught some kind
of assembler, a set of mnemonics that are assembled (translated) into
its binary equivalents in a much straighter fashion than any higher
level language.

I know few people that can do bits of debugging looking at binary
code. But I don't know anybody that actually prefers that to
assembler. It has no direct meaning for humans, much less so in
complex architectures such as x86 (MIPS has quite a bit of regularity,
so you can +- easily recognize some constructs, but still, assembler
is prefered).

Now, as to your question: When is said language taught? It would
*really* surprise me if you told me the University of Latvia taught
assembler to newcomer students. Students have to grasp the basics of
programming *and like it*. Some universities start with C; I don't
think it's a good idea: A much higher-level language (often Python is
chosen) makes it much easier to grasp the logic of stating the steps
of an algorithm to be executed in order, and will allow students to
better grasp programming paradigms, data types, etc.

At some point, lower-level languages should be studied. C is a great
example, as it exposes a lot of complexity while still being quite
human-readable.

I use bits of fake-assembler when showing some points in my class
about Operating Systems. The course on Compilers also benefits clearly
from assembler. It helps students understand what *actually* happens
when you do a given call. But I don't intend on teaching how to
actually program in assembler (I'd have to learn to do so first!)

I hope my opinion is useful to you.

Now, please note that basically nothing I said in this last couple of
paragraphs is Debian-related. Of course, you can do Debian development
in any language, including your favorite assembler. But you will find
you need many other higher level languages much more.


-- 
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/20140909234903.ga92...@gwolf.org

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Josh Triplett]

Michael Biebl wrote:
> Am 09.09.2014 17:15, schrieb Ansgar Burchardt:
> > Having only some systems switch to a different init system on upgrade
> > seems potentially confusing to me.
> 
> Agreed. We definitely should switch the machines on upgrades. There is a
> good reason why we also did it when switching to dependency based boot.
> 
>  That said, it would be nice if
> > systemd-sysv could check for common problems on installation and issue a
> > debconf warning, e.g. when not currently mounted entries are present in
> > /etc/fstab or when keyscripts for cryptsetup are used.
> 
> Nod. I'm planning to add such checks to systemd-sysv preinst (I think we
> already have a bug report open for that).
> 
> If it finds such issues on first installation, it will pop up a debconf
> prompt displaying the issues it found with some hints how to fix them
> and the choice to abort or continue with the installation.
> 
> Together with the /lib/sysvinit/init fallback binary in sysvinit and
> (and optionally my patch getting merged for grub [1]), this should
> provide for a hopefully seamless upgrade experience.

Agreed, this seems like the best plan: avoid prompting in the common
case, prompt in cases that might cause problems, and provide an easy
fallback.

In particular, given that /etc/init.d/* scripts are typically conffiles,
we could easily detect if they've been directly changed, and if so, warn
about edits (with a list of edited files) and point to information on
applying those changes to the corresponding systemd services.

- Josh Triplett


-- 
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/20140910010029.GA1693@jtriplet-mobl1

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Ben Hutchings]

On Tue, 2014-09-09 at 21:24 +0100, Noel Torres wrote:
> On Tuesday, 9 de September de 2014 21:18:55 Tollef Fog Heen escribió:
> > ]] Carlos Alberto Lopez Perez
> > 
> > > But if you don't (Is not uncommon to have servers on remote locations
> > > that are only accessible via ssh) and the machine don't boots properly
> > > you can find yourself in trouble.
> > 
> > Then surely you test the upgrade before making it live, using kvm
> > -snapshot or similar functionality?
> 
> This is simply not possible in physical live, productions servers on remote 
> CPDs.

In that case you test on your staging server first...

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


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

Re: More tasks option in Tasksel: what tasks do you want there? (reloaded)

[Paul Wise]

On Wed, Sep 10, 2014 at 5:57 AM, Markus Koschany wrote:

> Creating a games-all metapackage would be easily doable

As someone who has been trying to maintain a system (rather than
metapackage) that is basically that (plus a bunch of games removed
from Debian), I don't think it is actually that easy. You could do it
based on sections but there are things in the games section that
aren't really games and there are things in other sections that are
games. You could do it based on debtags but I don't think every game
is debtagged. You could do it based on files in /usr/games but not
every game uses that. You could do it based on a combination of these
things but there are a number of game variants/versions, some of which
conflict with each other. At the end of the day it would have to be a
curated list like all the games-* metapackages, possibly mostly based
on the above things.

> there was a more elegant way to solve this problem and if we could avoid
> the creation of "meta-metapackages". I could imagine another check box
> in tasksel for instance. If checked all separate installable games-*
> tasks for users would be selected and all tasks for developers and
> artists, the -dev packages, would be excluded.

That does sound interesting, but personally I would want a games-all
metapackage to exist.

-- 
bye,
pabs

https://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/CAKTje6FHUtvMZL63m_ZPq=acncshygleh5bxcw5xsxtubta...@mail.gmail.com

Re: Seeking help with OpenVPN scripts and systemd

[Andrey Rahmatullin]

On Tue, Sep 09, 2014 at 09:26:28PM +0100, Noel Torres wrote:
> openvpn package should Conflitcs systemd in order to avoid systemd being 
> installed 
ITYM "to avoid openvpn being installed".

-- 
WBR, wRAR


-- 
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/20140910042544.ga29...@belkar.wrar.name

Re: More tasks option in Tasksel: what tasks do you want there?

[Philipp Kern]

On Mon, Sep 08, 2014 at 11:38:05PM +0800, Thomas Goirand wrote:
> It's by the way surprising to see smartmontools, just as if monitoring
> HDD health is only important for a file server. My take: it's always
> important, whatever you do with a computer.

It should likely be raised to priority=standard, which would make it part of
the "standard system utilities" task. smartctl is relatively important for
problem diagnosis with disk drives.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: More tasks option in Tasksel: what tasks do you want there?

[Paul Wise]

On Wed, Sep 10, 2014 at 1:34 PM, Philipp Kern wrote:

> It should likely be raised to priority=standard, which would make it part of
> the "standard system utilities" task. smartctl is relatively important for
> problem diagnosis with disk drives.

I don't think it is necessary everywhere:

Various devices only have flash storage or storage that doesn't support SMART.

On desktop installs, udisks/udisks2 and the corresponding GUI parts
are more useful to the relevant persons.

-- 
bye,
pabs

https://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/caktje6exnbgwrkqaagsq6qg9hrehtot8urp1xla3wlqt_nj...@mail.gmail.com