Bug#760615: general: Shell scripts do not execute in gui.

[Kenji Takashima]

Package: general
Severity: important

Dear Maintainer,

I have been trying to execute multiple shell scripts in gui with no avail. The
scripts succesfully executed in a terminal, however in the gui, the files would
not execute when clicked on, and, when right-clicked, did not have a "run"
option. Other types of executables have worked, though I have not tested that
many.

Thanks,

Kenji Takashima



-- System Information:
Debian Release: jessie/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20140906025031.5120.23581.reportbug@debian

Re: Cinnamon environment now available in testing

[Ben Hutchings]

On Fri, 2014-09-05 at 16:01 -0700, Steve Langasek wrote:
> On Fri, Sep 05, 2014 at 11:48:04PM +0100, Ben Hutchings wrote:
> > On Fri, 2014-09-05 at 13:52 -0400, Zack Weinberg wrote:
> > > Steve Langasek wrote:
> 
> > > > No, that's not the true package relationship.  There's no reason that
> > > > you should always get this added service by default when you install
> > > > a system with non-systemd init that doesn't need logind.  Making this
> > > > a recommends would be a workaround for bad metadata in the
> > > > libpam-systemd package; we should fix that problem at its source the
> > > > right way.
> 
> > > I filed bug #746578 against libpam-systemd back in May; I believe the 
> > > proposed change (depend on systemd-shim | systemd-sysv rather than the 
> > > other way around) addresses most if not all of this class of issues.  It 
> > > is currently WONTFIXed.
> > [...]
> 
> > It's a bit counter-intuitive to have the default init system second, but
> > now that I think about it, I can see that it will do the right thing on
> > a jessie installation.
> 
> > Upgrades from wheezy are the problem.  Currently, upgrading sysvinit
> > should result in installing init and, unless upstart or sysvinit-core is
> > already installed, systemd-sysv.  But if sysvinit and some rdep of
> > libpam-systemd are upgraded at the same time, and the order of
> > libpam-systemd's dependencies is switched, APT (or other package
> > manager) might consider it preferable to install sysvinit-core and
> > systemd-shim.  Has this been tested?
> 
> systemd-shim expresses no preference for init system, and is completely
> coinstallable with systemd-sysv - and should be a no-op when booting under
> systemd because the dbus name is already taken.
[...]

Sorry, I misread the Breaks field in systemd-shim (the version is higher
than the current version of systemd in unstable).

If I understand the last changelog entry correctly, systemd-shim can
also be built against a later version of systemd and should get the
right versioned Breaks.  However, systemd-shim/experimental has been
built against systemd/unstable on i386, resulting in:

Package: systemd-shim
Version: 7-2exp1
Breaks: systemd (>= 209)

whereas on amd64 (maintainer build) it seems to have been built against
systemd/experimental and so has the intended:

Package: systemd-shim
Version: 7-2exp1
Breaks: systemd (<< 209)

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Re: Cinnamon environment now available in testing

[Steve Langasek]

On Fri, Sep 05, 2014 at 11:48:04PM +0100, Ben Hutchings wrote:
> On Fri, 2014-09-05 at 13:52 -0400, Zack Weinberg wrote:
> > Steve Langasek wrote:

> > > No, that's not the true package relationship.  There's no reason that
> > > you should always get this added service by default when you install
> > > a system with non-systemd init that doesn't need logind.  Making this
> > > a recommends would be a workaround for bad metadata in the
> > > libpam-systemd package; we should fix that problem at its source the
> > > right way.

> > I filed bug #746578 against libpam-systemd back in May; I believe the 
> > proposed change (depend on systemd-shim | systemd-sysv rather than the 
> > other way around) addresses most if not all of this class of issues.  It 
> > is currently WONTFIXed.
> [...]

> It's a bit counter-intuitive to have the default init system second, but
> now that I think about it, I can see that it will do the right thing on
> a jessie installation.

> Upgrades from wheezy are the problem.  Currently, upgrading sysvinit
> should result in installing init and, unless upstart or sysvinit-core is
> already installed, systemd-sysv.  But if sysvinit and some rdep of
> libpam-systemd are upgraded at the same time, and the order of
> libpam-systemd's dependencies is switched, APT (or other package
> manager) might consider it preferable to install sysvinit-core and
> systemd-shim.  Has this been tested?

systemd-shim expresses no preference for init system, and is completely
coinstallable with systemd-sysv - and should be a no-op when booting under
systemd because the dbus name is already taken.

So the worst case is that you get an extra, inert systemd-shim package
installed on upgrade.  It's not going to cause a different init system to be
selected.

Michael, is it clear to you why this change is needed, and can you
un-wontfix this bug please, to list systemd-shim as the first ORed
dependency as I've asked previously?

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


signature.asc
Description: Digital signature

Re: Cinnamon environment now available in testing

[Ben Hutchings]

On Fri, 2014-09-05 at 13:52 -0400, Zack Weinberg wrote:
> Steve Langasek wrote:
> 
> > No, that's not the true package relationship.  There's no reason that
> > you should always get this added service by default when you install
> > a system with non-systemd init that doesn't need logind.  Making this
> > a recommends would be a workaround for bad metadata in the
> > libpam-systemd package; we should fix that problem at its source the
> > right way.
> 
> I filed bug #746578 against libpam-systemd back in May; I believe the 
> proposed change (depend on systemd-shim | systemd-sysv rather than the 
> other way around) addresses most if not all of this class of issues.  It 
> is currently WONTFIXed.
[...]

It's a bit counter-intuitive to have the default init system second, but
now that I think about it, I can see that it will do the right thing on
a jessie installation.

Upgrades from wheezy are the problem.  Currently, upgrading sysvinit
should result in installing init and, unless upstart or sysvinit-core is
already installed, systemd-sysv.  But if sysvinit and some rdep of
libpam-systemd are upgraded at the same time, and the order of
libpam-systemd's dependencies is switched, APT (or other package
manager) might consider it preferable to install sysvinit-core and
systemd-shim.  Has this been tested?

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Re: x32: a success story, and thanks to you all!

[Ben Hutchings]

On Fri, 2014-09-05 at 17:29 +0100, Colin Watson wrote:
> On Fri, Sep 05, 2014 at 04:43:01PM +0100, Ben Hutchings wrote:
> > No, they should add amd64 as a foreign architecture.
> 
> Should we do this by default for x32 in d-i?  (Yes, I know d-i doesn't
> support x32 in other ways yet, but we might as well get started at some
> point.)

Yes I think so.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Russ Allbery]

Adam Borowski  writes:

> systemd also pulls in a large amount of bloat (IIRC someone mentioned
> 100ish packages in wheezy vs 146 in current jessie).  Purging those is
> nontrivial, as some had their priority bumped up.

That seems much higher than I believe is the case.  Wasn't there a
detailed analysis of this posted a while back?  My vague recollection was
a number more on the order of a quarter of that, and with most of those
being quite small (such as libsystemd-daemon0, which counts as a package
but which has an installed size of 72KB).

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

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Ansgar Burchardt]

Cameron Norman  writes:
> On Fri, Sep 5, 2014 at 5:20 AM, Matthias Urlichs  wrote:
>> In any case, IMHO a system that's been installed with wheezy, and
>> then upgraded to jessie, should be identical to a system installed with
>> jessie in the first place.
>
> Regardless of whether I agree or not, I do not think a good way to do
> this is through random dependencies of DE's or network manager.

They are not random, unless you mean random as in [1].

  [1] 

>> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> to switch to systemd (by whatever means, the details of which I personally
>> am not at all interested in), a dist-upgrade should do so.
>
> Currently, this is impossible, since systemd-shim DNE on Wheezy.

Nothing prevents you from a, installing systemd-shim from Jessie before
running apt-get dist-upgrade or b, using "apt-get dist-upgrade upstart".

I'm fairly sure I saw this question also answered on -user@ once or
twice times (which is also the appropriate list to ask such questions).

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/85lhpxn6sk@tsukuyomi.43-1.org

Re: systemd, again (Re: Cinnamon environment now available in testing)

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/05/2014 at 03:44 PM, Cameron Norman wrote:

> On Fri, Sep 5, 2014 at 5:20 AM, Matthias Urlichs 
>  wrote:

>> Thus, unless the user explicitly tells the apt{-get,itude} 
>> subsystem not to switch to systemd (by whatever means, the
>> details of which I personally am not at all interested in), a
>> dist-upgrade should do so.
> 
> Currently, this is impossible, since systemd-shim DNE on Wheezy.

But it should be possible to 'apt-get update ; apt-get install
systemd-shim ; apt-get dist-upgrade', and AFAICT that should get the job
done.

Alternately, it should be possible to pin systemd-sysv to "not
installed", even when no such package as systemd-sysv exists - and then
dist-upgrade should be able to figure out the necessary dependency
resolution.

- -- 
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUChsIAAoJEASpNY00KDJr2+AP/0fYWpMLkcRldnIhYRyS8O+P
IKo1tdxNuXMZhFCoVyuoDMg+FM1mc5Cze3tIQfXlsuBC9Z0IWS5Exz14LM7OAiRw
ZiNS3ev+AMQHEq4sc+x2v/Q7Ack3cHQ/Lfg05Qs3rsJAlB/wY5F/nVXvhS/B4jo3
X5JhZeZ0fU4hDQUvYDHrun5EktAGP78oGIQL2aYMmNIdgvhEDzesc57DAX7KVPX/
iBB/oTob5PCU1072488kTbJZlkbaX7PlNNAu2fyfYm8jKbIAJmtPiYooGN8W39Js
Awj5TdfkK00+cwyhmyghGk72NBzRIL0DWNIaHrD8l7xY32VKHiWuurGBQc+SQYZO
uIN8u+098vh8bQDpn/5PaDaJTylaOmdUHUozhNQsAfxBYbUw83fn8eDWVws8Gv5H
q2hlqbSd320+8JKT7zMvcF6VctepLaiAul/t/2uLZi1dkaP0cbrVL8n+CRKxGXJQ
Ber/hu9Ddd8TFLYOr/ViiiNJY/nn4+3qHXdyIS3GISGstF5AbU6wNywosabkxS1K
TPBHcQY0uYkIUNKUlaSxERKQOmmWQJ9Hg3zcPNY2bTEjIPyJ0uXKXlrxD0jwAyga
m5zsjWBcR+63yuIHBQa/7ES5haZmbUXL2AJZA+3leZONnj6aTC7jPJjoAM/LbbAl
D3PUW/XUQ9uK7ffRvPS3
=vbbB
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/540a1b08.5020...@fastmail.fm

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Cameron Norman]

On Fri, Sep 5, 2014 at 5:20 AM, Matthias Urlichs  wrote:
> Hi,
>
> Noel Torres:
>> * superior: plain no
>>
> Your opinion. Mine is "hell yes". Both opinions are completely worthless,
> absent any reasoning.
> Could we please stop the "systemd is good" vs. "systemd is bad" bashing?
>
> In any case, IMHO a system that's been installed with wheezy, and
> then upgraded to jessie, should be identical to a system installed with
> jessie in the first place.

Regardless of whether I agree or not, I do not think a good way to do
this is through random dependencies of DE's or network manager.

>
> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
> to switch to systemd (by whatever means, the details of which I personally
> am not at all interested in), a dist-upgrade should do so.

Currently, this is impossible, since systemd-shim DNE on Wheezy.

Best wishes,
--
Cameron Norman


-- 
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/CALZWFRJttF2DdbMfvF73sjTMRbDO9_388ruPtCg4doKSww=t...@mail.gmail.com

Re: Cinnamon environment now available in testing

[Cameron Norman]

On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette  wrote:
> Noel Torres wrote:
>> So we are clearly failing to follow the least surprise (for the user) path.
>>
>> Should not logind depend on systemd-shim | systemd-sysv instead?
>
> No. Systemd is the default init system. The default dependencies should
> reflect that.

It has already been explained that it being the default makes the
order switching irrelevant for what you recommend. If people are using
the default init, the dependency will already be satisfied and life
will not be disrupted. The same thing should happen if people are
using a different init: that decision should be maintained unless they
manually uninstall the package that satisfies the init package's
dependency.

>
> And from a purely functional point of view, it makes more sense to bring
> by default the standard, upstream-supported, well-tested solution, than
> the Debuntu-specific hack to use it with an inferior init system.

Another purely functional POV is that upgrading from wheezy to jessie
should not require switching your init system (or removing NM and
GNOME and more), as it does currently.

Cheers,
--
Cameron Norman


-- 
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/calzwfr+20rlwdsgcecbuvxqkkpojxfdo3oy3vf5o-wolveb...@mail.gmail.com

Re: x32: a success story, and thanks to you all!

[Colin Watson]

On Fri, Sep 05, 2014 at 08:14:27PM +0200, Adam Borowski wrote:
> On Fri, Sep 05, 2014 at 05:29:41PM +0100, Colin Watson wrote:
> > On Fri, Sep 05, 2014 at 04:43:01PM +0100, Ben Hutchings wrote:
> > > No, they should add amd64 as a foreign architecture.
> > 
> > Should we do this by default for x32 in d-i?  (Yes, I know d-i doesn't
> > support x32 in other ways yet, but we might as well get started at some
> > point.)
> 
> x32 has the following major use cases:
> * vserver hosting
> * underpowered netbooks
> * get-any-last-percent-of-speed number crunching
> 
> At least the first two prefer a small installed size, which means a pure
> system without two sets of binaries.

There's no reason why adding amd64 as a foreign architecture means two
sets of binaries.  If you don't want foreign-arch packages, don't
install them.  Adding the architecture just makes them available without
messing around.

This is especially important if installing the kernel is going to
require multiarch, as Ben said upthread.

-- 
Colin Watson   [cjwat...@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/20140905192301.ga24...@riva.ucam.org

Re: Cinnamon environment now available in testing

[Zack Weinberg]

On Fri, Sep 5, 2014 at 2:22 PM, Matthias Klumpp  wrote:
> 2014-09-05 19:52 GMT+02:00 Zack Weinberg :
>> Abstractly, I believe the ideal situation would be for all init systems in
>> the archive to be *completely* co-installable, with /sbin/init a symlink
>> under control of the administrator
...
> I did not test this, but AFAIK PID 1 can not be a symlink...

I did not test this either, but per
http://lxr.free-electrons.com/source/init/main.c#L906 and
http://lxr.free-electrons.com/source/init/main.c#L952 the kernel just
calls do_execve() on whatever init= parameter it's given or else a
short list of defaults (including "/sbin/init"), so symlinks _should_
work normally.

zw


-- 
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/cakcabmgbfkkd+7id3eabrvpdne9ymz0ycxo8l9v3oomqezc...@mail.gmail.com

Re: Transition handling in Debian (was: systemd, again)

[Matthias Urlichs]

Hi,

Daniel Leidert:
> Matthias Urlichs wrote:
> 
> >In any case, IMHO a system that's been installed with wheezy, and
> >then upgraded to jessie, should be identical to a system installed with
> >jessie in the first place.
> 
> That is nothing but wrong. [...]
> Your argument is only reasonable for a plain standard system, which a user
> did not alter.

Did I say "modified by the local sysadmin" in the above sentence? No.

> However, this is *well* less then 1 percent of all systems?
> 
Probably. So? We're talking about init systems. I daresay that the vast
majority of Debian systems out there do not have any locally-modified
scripts in /etc/init.d, which is about the only change that might be
ignored when you switch to systemd (depending on whether the package in
question now contains a systemd unit file).

> The discussion e.g. about switching between default desktop environments has 
> AFAIK
> NOT come to the conclusion, that we begin to touch the users system and change
> his/hers decision of which DE to use.

I don't recall anybody advocating this, so I don't quite understand what
your problem is.

> If the project decides to transition the default init system, that has to be
> expected, yes, like it was with apache1.4->2.0, many library transitions ...

AFAICT the systemd transition will be seamless and transparent for most
users. Most major upgrades of nontrivial packages (Apache1>2 is a good
example) are much more painful.

-- 
-- 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/20140905184111.gg21...@smurf.noris.de

Re: Cinnamon environment now available in testing

[Matthias Urlichs]

Hi,

Matthias Klumpp:
> I did not test this, but AFAIK PID 1 can not be a symlink...

Obviously. (And why couldn't it be a symlink?)

In fact:

# ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Aug 21 00:23 /sbin/init -> /lib/systemd/systemd
# 

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: 2 months and no upload for pkg

[Matthias Urlichs]

Hi,

Daniel Pocock:
> 
> >> c) offer a paid review service.  FTP masters and assistants can sell
> >> their time through an auction process.  [...]
> > 
> > I hope this is a joke.
> 
> Not entirely
> I was not suggesting people would pay to have their packages approved.
> Only that there would be payment for consideration.

I recall that the last time we went through this sort of argument,
numerous people have stated quite unequivocally that as soon as there is
any sort of direct monetary compensation for participating in some Debian
tasks, they're outta here.

I don't think that has changed, and thus I believe that the net amount of
work done for Debian is most likely to *de*crease if somebody does that
kind of thing.

TL;DR: Do Not Go There.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: 2 months and no upload for pkg

[Daniel Pocock]

On 05/09/14 18:45, Ian Jackson wrote:
> Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
>> This is really the root of the problem and I agree that it would be nice
>> to find ways to help them.  A solution is good for the FTP masters and
>> good for the project.
> 
> I agree.
> 
>> Another way to look at your proposal may be to compare it to
>> alternatives (I'm not suggesting I personally agree with all of these,
>> but they are just some things that come to mind):
>>
>> a) let people self-certify packages when they wrote 100% of the code
>> themselves.  People abusing this privilege would lose it.
>>
>> b) offer some facility for upstreams to certify their packages as 100%
>> free software by completing a DEP-5-like template and signing it with
>> the same key they use to sign their tags and release announcements.
> 
> I think both of these are, mostly, ad-hoc ways of prioritising certain
> packages.  (Since the effort of setting up such systems and monitoring
> compliance etc. is probably not less than that of reviewing the
> packages in question and coming to a judgement.)
> 
> A more flexible approach along the same lines would be to allow
> packages to skip manual NEW review if countersigned by N DDs (who
> would presumably lose countersigning privileges it was later
> discovered that the package should have been rejected).
> 
>> c) offer a paid review service.  FTP masters and assistants can sell
>> their time through an auction process.  [...]
> 
> I hope this is a joke.

Not entirely

I was not suggesting people would pay to have their packages approved.
Only that there would be payment for consideration.  If the payment was
completely transparent, if it motivated more people to join the FTP team
and if it increased throughput without compromising quality then it may
be worthy of discussion.

If it meant packages of a non-commercial nature were never getting
looked at then I personally would feel that is a loss for Debian.


>> d) the upload with binary JARs inside it was accepted by the NEW queue
>> software.  Maybe the scripts could be stricter about rejecting such
>> packages before they reach FTP masters?  Do the FTP masters publish
>> statistics on rejections that could be used to identify the top things
>> to scan and reject automatically?
> 
> I'm sure the ftpmasters will welcome your patches to their decision
> support software.

I'd be happy to comment on that further if anybody could point me to
statistics about the types of things to look for.  Maybe this could also
be a good idea for an OPW project?


-- 
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/540a035d.1010...@pocock.pro

Bug#760597: ITP: sosi2osm -- SOSI to OSM converter

[ruben . undheim]

Package: wnpp
Severity: wishlist
Owner: ruben.undh...@gmail.com


* Package name: sosi2osm
  Version : 1.0.0
  Upstream Author : Knut Karevoll 
* URL : https://github.com/Gnonthgol/sosi2osm
* License : GPL-2.0+
  Programming Lang: C++
  Description : SOSI to OSM converter

.
 This little utility converts .sosi files into .osm files which are 
 used by OpenStreetMap. It relies on the FYBA library released by the 
 Norwegian Mapping Authority (Statens kartverk).


-- 
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/20140905180955.3238.83339.reportbug@miniserver.granittvegen

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Adam Borowski]

On Fri, Sep 05, 2014 at 07:25:13PM +0200, Matthias Klumpp wrote:
> > And proposing a solution for a systemd-free (advanced) menu item in the
> > installer will be accepted too?
> If someone stands up and does the work, I guess so - but doing that is
> a non-trivial task, since systemd is seeded by debootstrap at a very
> early stage.
> It would probably be much less pain to simply swap systemd-sysv with
> sysvinit-core as soon as the system is installed.

systemd also pulls in a large amount of bloat (IIRC someone mentioned 100ish
packages in wheezy vs 146 in current jessie).  Purging those is nontrivial,
as some had their priority bumped up.

At least embedded systems and sbuilds do care about that extra space.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20140905181005.ga25...@angband.pl

Re: Cinnamon environment now available in testing

[Matthias Klumpp]

2014-09-05 19:52 GMT+02:00 Zack Weinberg :
> Steve Langasek wrote:
>
>> No, that's not the true package relationship.  There's no reason that
>> you should always get this added service by default when you install
>> a system with non-systemd init that doesn't need logind.  Making this
>> a recommends would be a workaround for bad metadata in the
>> libpam-systemd package; we should fix that problem at its source the
>> right way.
>
>
> I filed bug #746578 against libpam-systemd back in May; I believe the
> proposed change (depend on systemd-shim | systemd-sysv rather than the other
> way around) addresses most if not all of this class of issues.  It is
> currently WONTFIXed.
>
> Abstractly, I believe the ideal situation would be for all init systems in
> the archive to be *completely* co-installable, with /sbin/init a symlink
> under control of the administrator; under no circumstances would installing
> or upgrading any package change that symlink.  (It follows that systems
> upgraded from wheezy might wind up with systemd _installed_, but sysvinit
> would remain the active init until the local admin changed things manually.
> Obviously this would need to be documented.)
>
> This would necessitate that all packages depending on specific functionality
> from the _running_ init be capable of detecting its absence at runtime and
> gracefully degrading their behavior.  That may be nontrivial, but I believe
> that we need it _anyway_ so that when a system is deliberately converted
> from one init to another it continues to function more-or-less correctly
> until next rebooted.
>
> Unfortunately, it may be too late for this for jessie :-(
I did not test this, but AFAIK PID 1 can not be a symlink...
Cheers,
Matthias


-- 
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/CAKNHny96avseu=d-tr+pytjizp_tcfz_be57e31dxe3csoj...@mail.gmail.com

Re: x32: a success story, and thanks to you all!

[Adam Borowski]

On Fri, Sep 05, 2014 at 05:29:41PM +0100, Colin Watson wrote:
> On Fri, Sep 05, 2014 at 04:43:01PM +0100, Ben Hutchings wrote:
> > No, they should add amd64 as a foreign architecture.
> 
> Should we do this by default for x32 in d-i?  (Yes, I know d-i doesn't
> support x32 in other ways yet, but we might as well get started at some
> point.)

x32 has the following major use cases:
* vserver hosting
* underpowered netbooks
* get-any-last-percent-of-speed number crunching

At least the first two prefer a small installed size, which means a pure
system without two sets of binaries.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20140905181427.gb25...@angband.pl

Re: Cinnamon environment now available in testing

[Zack Weinberg]

Steve Langasek wrote:


No, that's not the true package relationship.  There's no reason that
you should always get this added service by default when you install
a system with non-systemd init that doesn't need logind.  Making this
a recommends would be a workaround for bad metadata in the
libpam-systemd package; we should fix that problem at its source the
right way.


I filed bug #746578 against libpam-systemd back in May; I believe the 
proposed change (depend on systemd-shim | systemd-sysv rather than the 
other way around) addresses most if not all of this class of issues.  It 
is currently WONTFIXed.


Abstractly, I believe the ideal situation would be for all init systems 
in the archive to be *completely* co-installable, with /sbin/init a 
symlink under control of the administrator; under no circumstances would 
installing or upgrading any package change that symlink.  (It follows 
that systems upgraded from wheezy might wind up with systemd 
_installed_, but sysvinit would remain the active init until the local 
admin changed things manually.  Obviously this would need to be documented.)


This would necessitate that all packages depending on specific 
functionality from the _running_ init be capable of detecting its 
absence at runtime and gracefully degrading their behavior.  That may be 
nontrivial, but I believe that we need it _anyway_ so that when a system 
is deliberately converted from one init to another it continues to 
function more-or-less correctly until next rebooted.


Unfortunately, it may be too late for this for jessie :-(

zw


--
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/5409f86c.1070...@panix.com

Re: Bug#760592: ITP: bsdowl -- bmake macros for building OCaml projects, TeX projects, and more

[Andrew Shadura]

Hello,

On Fri, 05 Sep 2014 18:57:50 +0200
Michael Gruenewald  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Michael Gruenewald 
> 
> * Package name: bsdowl
>   Version : 2.2.1
>   Upstream Author : Michael Gruenewald 
> * URL : https://bitbucket.org/michipili/bsdowl
> * License : CeCILL-B FREE SOFTWARE LICENSE AGREEMENT
>   Programming Lang: bmake
>   Description : bmake macros for building OCaml projects, TeX
> projects, and more

Michaël, does it have to be under CeCILL-B license? I have asked few
people I know who are quite well-educated regarding software licensing,
and they were uncertain about the status of this license.

I also see you used to distribute this piece of software under 3-clause
BSD license. What's wrong with it, why have you decided to switch?

By the way, it would be cool if you could integrate your makefiles to
mk-configure (or make them compatible with it), so mk-configure users
can benefit from them.

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Klumpp]

2014-09-05 17:23 GMT+02:00 Svante Signell :
> On Fri, 2014-09-05 at 16:07 +0200, Matthias Klumpp wrote:
>> 2014-09-05 15:12 GMT+02:00 Svante Signell :
>> > On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>
>> > How? All efforts so far and bugs reported are being brought down
>> > actively.
>> Install systemd-shim + sysvinit-core, or simply pin systemd-sysv will
>> be enough to install the shim and don't get systemd.
>> So yes, this is possible, and the systemd maintainers are doing a
>> great job in creating a seamless transition without blocking anyone
>> who doesn't want to use systemd for whatever reason.
>
> And proposing a solution for a systemd-free (advanced) menu item in the
> installer will be accepted too?
If someone stands up and does the work, I guess so - but doing that is
a non-trivial task, since systemd is seeded by debootstrap at a very
early stage.
It would probably be much less pain to simply swap systemd-sysv with
sysvinit-core as soon as the system is installed.
Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


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

Bug#760592: ITP: bsdowl -- bmake macros for building OCaml projects, TeX projects, and more

[Michael Gruenewald]

Package: wnpp
Severity: wishlist
Owner: Michael Gruenewald 

* Package name: bsdowl
  Version : 2.2.1
  Upstream Author : Michael Gruenewald 
* URL : https://bitbucket.org/michipili/bsdowl
* License : CeCILL-B FREE SOFTWARE LICENSE AGREEMENT
  Programming Lang: bmake
  Description : bmake macros for building OCaml projects, TeX projects, and 
more

This collection of BSD Make directives can be used to create
workflows including the following activities: Preparation and
publication of TeX documents; Development of TeX macros with NOWEB;
Development of OCaml software; Maintenance of a FreeBSD workstation
configuration files; Preparation of a static website with ONSGMLS.

I am willing to maintain the Debian package for this software I wrote,
and I probably need a sponsor to guide my first steps as a Debian
maintainer.


-- 
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/20140905165750.1279.7584.report...@onagh.celt.neu

Re: 2 months and no upload for pkg

[Scott Kitterman]

On Friday, September 05, 2014 18:21:28 Daniel Pocock wrote:
> On 05/09/14 17:48, Ian Jackson wrote:
> > It is true that long NEW processing queues is a big problem.  But it
> > appears that a substantial amount of core team effort is being used to
> > deal with poor submissions.  If we can fix that, we can fix the long
> > queue.
> 
> This is really the root of the problem and I agree that it would be nice
> to find ways to help them.  A solution is good for the FTP masters and
> good for the project.
> 
> Another way to look at your proposal may be to compare it to
> alternatives (I'm not suggesting I personally agree with all of these,
> but they are just some things that come to mind):
> 
> a) let people self-certify packages when they wrote 100% of the code
> themselves.  People abusing this privilege would lose it.
> 
> b) offer some facility for upstreams to certify their packages as 100%
> free software by completing a DEP-5-like template and signing it with
> the same key they use to sign their tags and release announcements.
> 
> c) offer a paid review service.  FTP masters and assistants can sell
> their time through an auction process.  Uploaders and interested third
> parties can bid for packages to be reviewed.  If they reject a package,
> it goes back to its original place in the queue unless somebody pays for
> them to spend more time on it.  Some people may feel that this will
> deter the FTP masters from reviewing packages unless all uploaders start
> paying while other people may feel that this funding would give the FTP
> masters more time.  Maybe the fee could include a surcharge of 33% to
> cover regular queue processing, so for every 3 packages that pay, one
> package is taken from the front of the queue as well?  The rate of the
> surcharge could be variable to keep the backlog within a 2 week target
> range.
> 
> d) the upload with binary JARs inside it was accepted by the NEW queue
> software.  Maybe the scripts could be stricter about rejecting such
> packages before they reach FTP masters?  Do the FTP masters publish
> statistics on rejections that could be used to identify the top things
> to scan and reject automatically?
> 
> Are there other alternatives that people can think of?

e) Stop uploading crap packages to the archive.

I know there are lots of ways to go wrong and it's time consuming and annoying 
and you're busy.  Imagine how much more annoying it is to have to deal with 
all of it.  The low quality of package uploads is (at least for me) 
demotivating.  As an FTP Assistant, I want time I invest in reviewing a 
package to result in something going into the archive.  Every time it doesn't 
I feel like I've had my time wasted.

Here's one tip I've given people before:

grep -ir copyright * 

Do that over your source and then compare what you have in debian/copyright.  
You might be surprised how often that turns up missing stuff.  Check your own 
packages at least as carefully as you expect the FTP Team to check it.

Scott K


-- 
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/4113890.BhKOUnD99M@scott-latitude-e6320

Re: 2 months and no upload for pkg

[Ian Jackson]

Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
> This is really the root of the problem and I agree that it would be nice
> to find ways to help them.  A solution is good for the FTP masters and
> good for the project.

I agree.

> Another way to look at your proposal may be to compare it to
> alternatives (I'm not suggesting I personally agree with all of these,
> but they are just some things that come to mind):
> 
> a) let people self-certify packages when they wrote 100% of the code
> themselves.  People abusing this privilege would lose it.
> 
> b) offer some facility for upstreams to certify their packages as 100%
> free software by completing a DEP-5-like template and signing it with
> the same key they use to sign their tags and release announcements.

I think both of these are, mostly, ad-hoc ways of prioritising certain
packages.  (Since the effort of setting up such systems and monitoring
compliance etc. is probably not less than that of reviewing the
packages in question and coming to a judgement.)

A more flexible approach along the same lines would be to allow
packages to skip manual NEW review if countersigned by N DDs (who
would presumably lose countersigning privileges it was later
discovered that the package should have been rejected).

> c) offer a paid review service.  FTP masters and assistants can sell
> their time through an auction process.  [...]

I hope this is a joke.

> d) the upload with binary JARs inside it was accepted by the NEW queue
> software.  Maybe the scripts could be stricter about rejecting such
> packages before they reach FTP masters?  Do the FTP masters publish
> statistics on rejections that could be used to identify the top things
> to scan and reject automatically?

I'm sure the ftpmasters will welcome your patches to their decision
support software.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21513.59577.820658.49...@chiark.greenend.org.uk

Re: Cinnamon environment now available in testing

[Steve Langasek]

On Fri, Sep 05, 2014 at 05:05:31PM +0100, Ben Hutchings wrote:
> On Fri, 2014-09-05 at 08:47 -0700, Steve Langasek wrote:
> > On Fri, Sep 05, 2014 at 10:57:34AM +0200, Josselin Mouette wrote:
> > > Noel Torres wrote: 
> > > > So we are clearly failing to follow the least surprise (for the user) 
> > > > path.

> > > > Should not logind depend on systemd-shim | systemd-sysv instead?

> > > No. Systemd is the default init system. The default dependencies should
> > > reflect that. 

> > No, the default dependencies should reflect the *principle of least
> > surprise*.  Installation of logind causing your init system to be changed if
> > you have already selected a non-default init system in jessie is failing
> > this principle.

> > The selection of default init system should be done via the Essential
> > packages *only*.

> In that case, perhaps the alternate init systems should Recommend
> systemd-shim?

No, that's not the true package relationship.  There's no reason that you
should always get this added service by default when you install a system
with non-systemd init that doesn't need logind.  Making this a recommends
would be a workaround for bad metadata in the libpam-systemd package; we
should fix that problem at its source the right way.

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


signature.asc
Description: Digital signature

Re: x32: a success story, and thanks to you all!

[Colin Watson]

On Fri, Sep 05, 2014 at 04:43:01PM +0100, Ben Hutchings wrote:
> No, they should add amd64 as a foreign architecture.

Should we do this by default for x32 in d-i?  (Yes, I know d-i doesn't
support x32 in other ways yet, but we might as well get started at some
point.)

-- 
Colin Watson   [cjwat...@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/20140905162941.ga18...@riva.ucam.org

Re: 2 months and no upload for pkg

[Daniel Pocock]

On 05/09/14 17:48, Ian Jackson wrote:

> It is true that long NEW processing queues is a big problem.  But it
> appears that a substantial amount of core team effort is being used to
> deal with poor submissions.  If we can fix that, we can fix the long
> queue.
> 

This is really the root of the problem and I agree that it would be nice
to find ways to help them.  A solution is good for the FTP masters and
good for the project.

Another way to look at your proposal may be to compare it to
alternatives (I'm not suggesting I personally agree with all of these,
but they are just some things that come to mind):

a) let people self-certify packages when they wrote 100% of the code
themselves.  People abusing this privilege would lose it.

b) offer some facility for upstreams to certify their packages as 100%
free software by completing a DEP-5-like template and signing it with
the same key they use to sign their tags and release announcements.

c) offer a paid review service.  FTP masters and assistants can sell
their time through an auction process.  Uploaders and interested third
parties can bid for packages to be reviewed.  If they reject a package,
it goes back to its original place in the queue unless somebody pays for
them to spend more time on it.  Some people may feel that this will
deter the FTP masters from reviewing packages unless all uploaders start
paying while other people may feel that this funding would give the FTP
masters more time.  Maybe the fee could include a surcharge of 33% to
cover regular queue processing, so for every 3 packages that pay, one
package is taken from the front of the queue as well?  The rate of the
surcharge could be variable to keep the backlog within a 2 week target
range.

d) the upload with binary JARs inside it was accepted by the NEW queue
software.  Maybe the scripts could be stricter about rejecting such
packages before they reach FTP masters?  Do the FTP masters publish
statistics on rejections that could be used to identify the top things
to scan and reject automatically?

Are there other alternatives that people can think of?


-- 
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/5409e308.3080...@pocock.pro

Transition handling in Debian (was: systemd, again)

[Daniel Leidert]

Matthias Urlichs wrote:

>In any case, IMHO a system that's been installed with wheezy, and
>then upgraded to jessie, should be identical to a system installed with
>jessie in the first place.

That is nothing but wrong. A system upgraded will (very probably) have a
different configuration - because we don't touch configuration files altered
by the user - and it can also have a different MTA, GCC, Kernel etc.pp. either
by updated-alternatives or by not having dependency-packages installed or 
Your argument is only reasonable for a plain standard system, which a user
did not alter. IIRC we do require this upgrade path by policy for such system.
However, this is *well* less then 1 percent of all systems?

The discussion e.g. about switching between default desktop environments has 
AFAIK
NOT come to the conclusion, that we begin to touch the users system and change
his/hers decision of which DE to use. If a user wants that, IMO we should 
provide a
dependency package like gcc or linux-image, because the DE or the kernel is 
vital
in many cases. If there is no such package, how do you come to the conclusion,
that you can force e.g. the default kernel or DE shipped with Jessie to be in
place on the upgraded system? Thus the decision to transition a system to a 
different
default has to be a sensitive one, because most systems won't be plain standard 
systems.

Otherwise you behave nothing better then Microsoft: installing updates even if
the user has chosen to download them only.

>Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>to switch to systemd (by whatever means, the details of which I personally
>am not at all interested in), a dist-upgrade should do so.

If the project decides to transition the default init system, that has to be
expected, yes, like it was with apache1.4->2.0, many library transitions ...
AFAIK it has also been suggested to handle the init system transition via
dependency packages (IIRC called init? not sure). IMO this could be a sensitive
technical decision for all those, who would like to keep things working as
they are or those who prefer a different init system.

Regards, Daniel


-- 
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/trinity-f4267db3-db33-46c5-8550-6f73fe2c4a1c-1409932604685@3capp-gmx-bs68

Re: Cinnamon environment now available in testing

[Ben Hutchings]

On Fri, 2014-09-05 at 08:47 -0700, Steve Langasek wrote:
> On Fri, Sep 05, 2014 at 10:57:34AM +0200, Josselin Mouette wrote:
> > Noel Torres wrote: 
> > > So we are clearly failing to follow the least surprise (for the user) 
> > > path.
> 
> > > Should not logind depend on systemd-shim | systemd-sysv instead?
> 
> > No. Systemd is the default init system. The default dependencies should
> > reflect that. 
> 
> No, the default dependencies should reflect the *principle of least
> surprise*.  Installation of logind causing your init system to be changed if
> you have already selected a non-default init system in jessie is failing
> this principle.
> 
> The selection of default init system should be done via the Essential
> packages *only*.

In that case, perhaps the alternate init systems should Recommend
systemd-shim?

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Re: Cinnamon environment now available in testing

[Steve Langasek]

On Fri, Sep 05, 2014 at 10:57:34AM +0200, Josselin Mouette wrote:
> Noel Torres wrote: 
> > So we are clearly failing to follow the least surprise (for the user) path.

> > Should not logind depend on systemd-shim | systemd-sysv instead?

> No. Systemd is the default init system. The default dependencies should
> reflect that. 

No, the default dependencies should reflect the *principle of least
surprise*.  Installation of logind causing your init system to be changed if
you have already selected a non-default init system in jessie is failing
this principle.

The selection of default init system should be done via the Essential
packages *only*.

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


signature.asc
Description: Digital signature

Re: 2 months and no upload for pkg

[Ian Jackson]

Daniel Pocock writes ("Re: 2 months and no upload for pkg"):
> There is one package I recently uploaded where I meant to use a
> repackaged tarball to get rid of an embedded binary toolchain JAR.  This
> is a more nasty mistake of course but thanks to the diligence of the FTP
> masters it was spotted.

Perhaps you were just unlucky.  If so then one REJECT out of many
ACCEPTs is not going to be a problem for you.  If you were not just
unlucky then the expected error rate in your NEW uploads is too high.
It is your responsibility to fix that, not the responsibility of the
rest of the project to help you, or to deal with the fallout, or to
bear the costs of unnecessary re-review.

> This also brings up one other concern about a procedure that
> deliberately defers processing of some items in the NEW queue:

My proposal does not deliberately defer processing of any NEW items.

I'm proposing _prioritising_ NEW processing, biasing it in favour of
(a crude predictor of) packages likely to be ACCEPTed and therefore
likely to quickly improve Debian by their presence.

> it may give an advantage to derivative distributions that are
> cherry-picking the best things from NEW and appear to be getting
> them faster than Debian.

I don't understand why you think this is less likely to be a problem
with the packages that my proposal prioritises than with the packages
tht my proposal deprioritises.

It is true that long NEW processing queues is a big problem.  But it
appears that a substantial amount of core team effort is being used to
deal with poor submissions.  If we can fix that, we can fix the long
queue.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21513.56124.749649.483...@chiark.greenend.org.uk

Re: x32: a success story, and thanks to you all!

[Ben Hutchings]

On Fri, 2014-09-05 at 12:51 +0200, Thorsten Glaser wrote:
[...]
> There are a few missing things. klibc builds for amd64 on x32,
> which I will probably fix myself as it needs porting (upstream
> is happy about me doing it); grub needs porting (or needs to
> build for amd64 or i386 on x32) which I may have a look at
> later; various multimedia stuff needs touching or at least
> disabling asm code (Daniel looks at it, and I will do so too),
> and we need src:linux to build linux-image-3.14-2-amd64:x32
> so people can run a non-M-A x32 installation eventually
[...]

No, they should add amd64 as a foreign architecture.  The wrong-
architecture kernel packages are a workaround from pre-multi-arch days
that I don't wish to extend.

Several things are still broken in kernel support; at least:
- Many ioctls 
- Syscall auditing 

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


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

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Svante Signell]

On Fri, 2014-09-05 at 16:07 +0200, Matthias Klumpp wrote:
> 2014-09-05 15:12 GMT+02:00 Svante Signell :
> > On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:

> > How? All efforts so far and bugs reported are being brought down
> > actively.
> Install systemd-shim + sysvinit-core, or simply pin systemd-sysv will
> be enough to install the shim and don't get systemd.
> So yes, this is possible, and the systemd maintainers are doing a
> great job in creating a seamless transition without blocking anyone
> who doesn't want to use systemd for whatever reason.

And proposing a solution for a systemd-free (advanced) menu item in the
installer will be accepted too?



-- 
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/1409930600.2303.6.camel@PackardBell-PC

Bug#760586: ITP: python-pint -- define, operate and manipulate physical quantities

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-pint
  Version : 0.5.2
  Upstream Author : Hernan Grecco 
* URL : https://github.com/hgrecco/pint
* License : BSD-3-clauses
  Programming Lang: Python
  Description : define, operate and manipulate physical quantities

 Pint is Python module/package to define, operate and manipulate physical
 quantities: the product of a numerical value and a unit of measurement. It
 allows arithmetic operations between them and conversions from and to
 different units.
 .
 It is distributed with a comprehensive list of physical units, prefixes and
 constants. Due to its modular design, you can extend (or even rewrite!) the
 complete list without changing the source code.


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

Re: daemon user naming scheme

[Thorsten Glaser]

On Fri, 5 Sep 2014, Ian Jackson wrote:

> Simon McVittie writes ("Re: daemon user naming scheme"):
> > It is reasonable to use /var/lib/foo (or /run/foo or /var/cache/foo or
> > /var/games/foo) as the home directory of a system user whose name is
> > _foo, debian-foo, Debian-foo or whatever.
> 
> You need to be careful that the directory chosen never has undesirable
> permissions, since there are many ways that access can be granted to a
> user foo by putting things in ~foo.

You could use /nonexistent as dæmon user home directory,
but only if pam_mkhomedir gets patched to never create it…

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
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/alpine.deb.2.11.1409051712300.31...@tglase.lan.tarent.de

Re: daemon user naming scheme

[Simon McVittie]

On 05/09/14 16:03, Ian Jackson wrote:
> Simon McVittie writes ("Re: daemon user naming scheme"):
>> It is reasonable to use /var/lib/foo (or /run/foo or /var/cache/foo or
>> /var/games/foo) as the home directory of a system user whose name is
>> _foo, debian-foo, Debian-foo or whatever.
> 
> You need to be careful that the directory chosen never has undesirable
> permissions, since there are many ways that access can be granted to a
> user foo by putting things in ~foo.

Yes, a good point which I should have mentioned. Please read as "it is
reasonable to use ... as long as that directory's permissions only allow
that user to write there".

> For example, /var/games/foo seems like a bad idea since it will
> probably be g+w games.

Hmm, not on my system - /var/games is 0755 root:root, and the
openarena-server and quake{,2,3}-server subdirectories created by my
Quake-based game packages are 0755 some-daemon-user:games.

I agree that if the foo subdirectory in games was used for a system-wide
shared high-score table or something (g+w games, with the game setgid
games so it can write there), then that would make it unsuitable. On the
other hand, using setgid for shared high-score tables on a multi-user
system has always seemed to me like using a sledgehammer (or possibly a
railgun) to crack a nut :-)

S


-- 
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/5409d2d4.4070...@debian.org

Re: daemon user naming scheme

[Ian Jackson]

Simon McVittie writes ("Re: daemon user naming scheme"):
> It is reasonable to use /var/lib/foo (or /run/foo or /var/cache/foo or
> /var/games/foo) as the home directory of a system user whose name is
> _foo, debian-foo, Debian-foo or whatever.

You need to be careful that the directory chosen never has undesirable
permissions, since there are many ways that access can be granted to a
user foo by putting things in ~foo.

For example, /var/games/foo seems like a bad idea since it will
probably be g+w games.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21513.53418.4646.993...@chiark.greenend.org.uk

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Klumpp]

2014-09-05 15:12 GMT+02:00 Svante Signell :
> On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>> Hi,
>
>> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> to switch to systemd (by whatever means, the details of which I personally
>> am not at all interested in), a dist-upgrade should do so.
>
> How? All efforts so far and bugs reported are being brought down
> actively.
Install systemd-shim + sysvinit-core, or simply pin systemd-sysv will
be enough to install the shim and don't get systemd.
So yes, this is possible, and the systemd maintainers are doing a
great job in creating a seamless transition without blocking anyone
who doesn't want to use systemd for whatever reason.

Cheers,
Matthias

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny9TmwgfmK2X2p7VANmLZqFjUSBWA_0Q=y7mnzb0ga4...@mail.gmail.com

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Svante Signell]

On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
> Hi,

> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
> to switch to systemd (by whatever means, the details of which I personally
> am not at all interested in), a dist-upgrade should do so.

How? All efforts so far and bugs reported are being brought down
actively.



-- 
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/1409922770.2303.2.camel@PackardBell-PC

Re: x32: a success story, and thanks to you all!

[Colin Watson]

On Fri, Sep 05, 2014 at 12:51:41PM +0200, Thorsten Glaser wrote:
> grub needs porting (or needs to build for amd64 or i386 on x32) which
> I may have a look at later;

Hopefully not difficult:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760428

-- 
Colin Watson   [cjwat...@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/20140905124046.ga12...@riva.ucam.org

systemd, again (Re: Cinnamon environment now available in testing)

[Matthias Urlichs]

Hi,

Noel Torres:
> * superior: plain no
> 
Your opinion. Mine is "hell yes". Both opinions are completely worthless,
absent any reasoning.
Could we please stop the "systemd is good" vs. "systemd is bad" bashing?

In any case, IMHO a system that's been installed with wheezy, and
then upgraded to jessie, should be identical to a system installed with
jessie in the first place.

Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
to switch to systemd (by whatever means, the details of which I personally
am not at all interested in), a dist-upgrade should do so.

-- 
-- 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/20140905122020.gf21...@smurf.noris.de

Re: Cinnamon environment now available in testing

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/05/2014 at 07:26 AM, The Wanderer wrote:

> On 09/05/2014 at 04:57 AM, Josselin Mouette wrote:
> 
>> Noel Torres wrote:
> 
>>> So we are clearly failing to follow the least surprise (for
>>> the user) path.
>>> 
>>> Should not logind depend on systemd-shim | systemd-sysv
>>> instead?
> 
>> No. Systemd is the default init system. The default dependencies 
>> should reflect that.
> 
> Is there any clear consensus on what it means to be the "default"
> in this context?
> 
> There are multiple possible meanings, and I think some of the 
> disputes which have arisen may be rooted at least partly in 
> disagreement about which of those meanings applies.
> 
> One possible meaning would be "the init system which will be 
> installed as active by the default debian-installer, unless the
> user explicitly selects otherwise". By itself, that would not mean
> that package dependencies should necessarily prefer systemd over
> any other init system, though there might be reasons in some cases
> for doing them differently anyway - such as, in the case at hand, 
> avoiding causing people to switch from one init system to the
> other without realizing what they're doing or how to avoid doing
> it.

I attached this "such as" section to the wrong paragraph, in editing
before send; it belongs on the other given possible meaning, below. My
apologies for any confusion this may cause.

> Another possible meaning would be "the init system which is 
> recommended to be used unless there is active reason to do 
> otherwise", which is a stronger statement. That would indeed more 
> support the idea that package dependencies should prefer systemd 
> over other init systems, though again, there might be reasons in
> any given case for doing them differently.
> 
> There may well be other potential meanings - I think I've run
> across at least one more in the past - but that should serve as
> examples, at least.
> 
> Would it be worth clarifying what the participants in this
> discussion (and possibly similar ones) understand "default" as
> meaning in the context of "default init system for jessie", and
> possibly clarifying that more officially on a broader scale for
> future reference?

- -- 
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUCZ7EAAoJEASpNY00KDJrSAMP/RA+gKHqVfFSK90DHiq4Q6IF
E8rnIXtMmzG178FUWXjrs2L/hOI/M2OIvUykCHtqx/qgbWjLqBMdMAtDTxFpdyLD
niQhEC4EuCtj2yPmT4UkgV05Vb1VkpawUAV4HXgzTuGWBZ/Waj55W7LtdC4Jn7FM
OyeevzrctQ+423ipqSG6oPnhTAshxdOt/GO6XITwXVUbz8A/pq8oijf+N9p7nwHw
iioH8JeRotTdl2GOmCN1QOA8e3EIJO2qk7KQbL+BoPcNYokzKHFiqs4azqEqqw2r
Slr2z8i1iMAuLqwHjlyU1yNY6+mUMmkrlhztm/DTA6GrQ2QlHMpoIwo+UC8tLEvO
bP9AN3XyI0TUOLPfbV8j1VqySeEkmR6yI9cbmI1wT7MZNZ3beIfiYH6YASOoKjCS
WLoUQL7BCiGzBM7H70FgDKivcvv6uA4Gh4PUBe+qSaN0/yJ25deQXPeGvD37G0Hg
hinimpMX3ZIORSYopVrSywV07Abv8o4T/hA4LxZIC+jv6pbNpBnzfckOHdbweCJM
zenZeVFSdbvlDxTVMVZod2hdTBgyGYOdPcw+iijaiwccxJyE0PqHOAuxFxokZrHT
yy6BJPRLqHeu17bqArq3kbHUNpTT/hSvBkXV3fvbtF6mqsmbcQjqNmjnSzw0xmJY
n3tMAMk+/rw9D3xzrs2w
=J9s8
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54099ec4.1040...@fastmail.fm

Re: Cinnamon environment now available in testing

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/05/2014 at 04:57 AM, Josselin Mouette wrote:

> Noel Torres wrote:
> 
>> So we are clearly failing to follow the least surprise (for the 
>> user) path.
>> 
>> Should not logind depend on systemd-shim | systemd-sysv instead?
> 
> No. Systemd is the default init system. The default dependencies 
> should reflect that.

Is there any clear consensus on what it means to be the "default" in
this context?

There are multiple possible meanings, and I think some of the disputes
which have arisen may be rooted at least partly in disagreement about
which of those meanings applies.

One possible meaning would be "the init system which will be installed
as active by the default debian-installer, unless the user explicitly
selects otherwise". By itself, that would not mean that package
dependencies should necessarily prefer systemd over any other init
system, though there might be reasons in some cases for doing them
differently anyway - such as, in the case at hand, avoiding causing
people to switch from one init system to the other without realizing
what they're doing or how to avoid doing it.

Another possible meaning would be "the init system which is recommended
to be used unless there is active reason to do otherwise", which is a
stronger statement. That would indeed more support the idea that package
dependencies should prefer systemd over other init systems, though
again, there might be reasons in any given case for doing them
differently.

There may well be other potential meanings - I think I've run across at
least one more in the past - but that should serve as examples, at
least.

Would it be worth clarifying what the participants in this discussion
(and possibly similar ones) understand "default" as meaning in the
context of "default init system for jessie", and possibly clarifying
that more officially on a broader scale for future reference?

- -- 
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJUCZ3hAAoJEASpNY00KDJrvooP/Rrb0O0IjTK+PN2uLtiHUOjZ
JcmNZXGuTzsvsNCLMaTwXbi1kGQJtrA3DuiKtG5E2AtHC7j7gSctwB/peGBLlXwp
wMOFtn2pfWrwWpFQ10VWxCpUvq6fj/wQ4boIjuapXJ91N+KCbO/ydh8TW2gNGbcE
catB5qVbAZDP1iTZkydTpj55PGe8wiSrd0EfXgGSxDbNM6cSPRkWSNL++TGq+G/s
0mf6rwZ1vwopMxurYpwwI0kl1653XI5Nw4L09vjg4Gq8QZkaMFPLBcRv3v6cIOJ0
WThqvN9fBQCVI7+1bAZ7lnWiX55CQtTJkxe9x7Klqqw6yIJjgG2O+XNiDYpI/Btc
ZTiV6P8q229aBHS1WVAnpq2lfjPTTfSgPCjLom+vnuwPJ/k+aH2WdQtxzQxpAWYR
LMIvA5Yx7qpSWjrVoMK2vmLgtpS8XDMTTlIDHviTRQdslsJWo+kvXqQ50wb7s+wA
x1GNeS67haI81R9YlSNgIr3Q6zuHQG0H4dd6Bxw42b2l7Rvqel0JUUk5hfVeZP4e
TOMPop6bqatcxOAB2oU7z79A8yyhsSuO6jgQvLinp/OUUxT7jE8G0lAP7A0uIUmM
kxpMLmk+9MQOBcLAFkSQGXX+hqHxNyweq3OCfKpPTIIJeT1Sv72kzxfwQQcmvqSV
xEKu72QfdyE0kzZhuShv
=glMk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54099de1.5080...@fastmail.fm

Re: Cinnamon environment now available in testing

[Noel Torres]

On Friday, 5 de September de 2014 09:57:34 Josselin Mouette escribió:
> Noel Torres wrote:
> > So we are clearly failing to follow the least surprise (for the user)
> > path.
> > 
> > Should not logind depend on systemd-shim | systemd-sysv instead?
> 
> No. Systemd is the default init system. The default dependencies should
> reflect that.
> 
> And from a purely functional point of view, it makes more sense to bring
> by default the standard, upstream-supported, well-tested solution, than
> the Debuntu-specific hack to use it with an inferior init system.
> 
> Cheers,

"Inferior" is your personal (and others) opinion. I do not think systemd being 
clearly superior. It has better points that sysvinit but also worse points 
(already extensively discussed). So that is not a reason to force users 
install systemd when they are just upgrading their currently working systems.

So:
* standard: we chose so (against the opinion of a lot of people), nothing more 
to discuss about that
* upstream-supported: not exclusive to systemd
* well-tested: not true. sysvinit is the well tested, and well known one 
(including its quircks and lacks)
* superior: plain no

Regards


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

x32: a success story, and thanks to you all!

[Thorsten Glaser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Hi everyone,

some might have noticed that, once the Debian Linux Kernel Maintainers
activated x32 support in the standard Debian kernels, I cross-graded my
machine at work to it.

I would like to say thanks to the various maintainers involved in this:

• Aurélien for debian-ports, as before with m68k
• Daniel for agreeing I could help
• the dpkg maintainers for making this possible
• the apt maintainers for making it, while not always pain-free,
  surprisingly well-working (e.g. I had to
  $ sudo apt-get --purge dist-upgrade libkolabxml1:i386-
  to upgrade kdepim, but then, being conservative and keeping
  packages in the arch they are installed for is probably
  better than overzealously installing them)
• Michael Vogt especially for adding the above syntax to apt-get ☺
• various package maintainers and upstreams for quickly adding
  Multi-Arch annotations (e.g. gettext) or patches to their
  packages or actively working on it (I just noticed nss/nspr
  will soon work; I still need them for :i386 too)

I’m very impressed with both that cross-grading works well
and that running an only partially cross-graded M-A system
works amazingly well, modulo the ability to run dselect.
And it all works without systemd, even ;-)

Thanks to you all!

There are a few missing things. klibc builds for amd64 on x32,
which I will probably fix myself as it needs porting (upstream
is happy about me doing it); grub needs porting (or needs to
build for amd64 or i386 on x32) which I may have a look at
later; various multimedia stuff needs touching or at least
disabling asm code (Daniel looks at it, and I will do so too),
and we need src:linux to build linux-image-3.14-2-amd64:x32
so people can run a non-M-A x32 installation eventually (once
the bootloader issue is sorted out, but I imagine LOADLIN.EXE
would also work), and until then, gcc-4.8:i386 needs to work
with binutils:x32 instead of requiring binutils:i386 (which
I worked around by hand-editing /var/lib/dpkg/status, yes I
know, bad me). But I’ve not heard of anything or anybody that
actively stands in the way of the x32 port progressing, now.

I just wanted to write a pure-positive port once in a while,
and express my gratitude to my fellow Debian Developers.

Sending from my work eMail because I consider all my work on
the x32 port, even if much is done in my spare time, also a
contribution by tarent who are letting me “play around” a bit
as long as I get my tasks done (and enjoy the synergy effects).

Please consider following up in private to keep the mailing
list noise down, unless you feel your response is something
you want to share with hundreds or thousands of subscribers.

bye,
//mirabilos
- -- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: ☃ ЦΤℱ—８　☕☂☄

iQIcBAEBCQAGBQJUCZW1AAoJEIlQwYleuNOz0+wP/1cvJq1vAcACK68KJEODTwb5
6A8NEcDo+XV82EkVOhot9RitKXhHz41g1i4eWoSdvU9C6nXPbrtlZoUuxe5fR6td
UuV7zzvRGyEbg7GvWBusDVjFqGKMwLNrpwL/guk25V33ZP2UDvJPA9vCHvSFV9YZ
tgw+TZFyqcr5M/t8BsgM62Dj4+Z34sDV0jymGU79T9dXChFgvfawXQM6Vy7BFCnD
bOceFbq69oyHn5PL9ho+ku0uxwf2fz6lzfkIrcspNnBnuNNslUDUN4zttnAw4O94
3em7UBy0KNhdsgkf/YghTsP6SSkICkRhQDOwM+54tYdT6pYx5nSAhtiEgN1wE+Y+
4WWUWAF0R+nFNAdSEJOVRsDbRnYptiFFYgJ95bZJbj9Lvr2xWlSQZuXs0QzzOtZW
ssx6I18Eyauy9odVVHqjz92xCbXswnRdjo6vOXD46vyvyFR7JT9pI/gigENj/P0S
/UDuBqWN7QpMPiIlnpy2TwvDXJcX7+922bEHr46dkxJw/KdJf/2wLlog/Yry/94J
t6IXxeR1kcq75/37xNEFIDrt6hY6FA5mlSxhsbIOoLRfOCEw4LQTsamT8LnJCnPL
UaeiGCTxC68NeNBr0ppcuXOYB4/+X7Cg+F1QlEKzFKMXRiuZ+y5UVH/fHl1g9vp8
+pr2UQFmIw9jNJsGzUjl
=GVDf
-END PGP SIGNATURE-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/alpine.deb.2.11.1409051240500.31...@tglase.lan.tarent.de

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Charles Plessy]

Le Fri, Sep 05, 2014 at 11:13:40AM +0200, Thorsten Glaser a écrit :
> 
> So please, do not outright dismiss scenarios you personally
> cannot imagine.

Please consider that your comments on the limited imagination of others can be
felt as deliberately offensive.

Cheers,

-- 
Charles Plessy


-- 
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/20140905092631.gd31...@falafel.plessy.net

Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages

[Thorsten Glaser]

On Fri, 5 Sep 2014, Changwoo Ryu wrote:

> As I said, such lowmem embeded devices don't even need to install big
> packages.

Just you saying so doesn’t make it (more) true. Debian is a
universal operating system… at least it tries to. Maybe one
of these packages contains _one_ file you need to build some
Teχ document, and your platform to do that is the smallest
GPLhost.fr server, which has a mere 128 MiB RAM, and which
would be perfectly fine doing just that. (Okay, bad example,
as it’s also HDD-size-constrained, but there’s always nbd
or other options to enlarge that, such as asking the owner.)

So please, do not outright dismiss scenarios you personally
cannot imagine.

Thanks.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
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/alpine.deb.2.11.140905320.31...@tglase.lan.tarent.de

Re: Cinnamon environment now available in testing

[Josselin Mouette]

Noel Torres wrote: 
> So we are clearly failing to follow the least surprise (for the user) path.
> 
> Should not logind depend on systemd-shim | systemd-sysv instead?

No. Systemd is the default init system. The default dependencies should
reflect that. 

And from a purely functional point of view, it makes more sense to bring
by default the standard, upstream-supported, well-tested solution, than
the Debuntu-specific hack to use it with an inferior init system. 

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



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

Re: Jessie without systemd as PID 1?

[Noel Torres]

On Wednesday, 3 de September de 2014 16:21:31 Svante Signell escribió:
[...]
> should be allowed, and I'm trying to find out how many of debian users
> and developers are interested in working together with me on such a
> solution. Best would be to have an option in the installer (hidden by
[...]

I volunteer to test this, not for contributing (I am not a programmer), for a 
very simple reason: I do not want my long-running servers (and those of my 
clients) to be rebooted for something that should be so simple as upgrading a 
service or applying some non-kernel security patch.

I may have (I agree I have) some conservative thinking. I've been well against 
network-manager messing my interfaces and I'm against systemd as well, but I 
really think the Unix way, when properly implemented, is the way to go. And if 
it does not work, make it work instead of building a dinosaur and force 
dependencies into it (and yes, I'm pointing at you, Gnome Debian packagers, 
both for network-manager and systemd).

In resume: count on me to test and check and report bugs and triage.

Noel
er Envite


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

Re: Cinnamon environment now available in testing

[Noel Torres]

On Friday, 5 de September de 2014 02:37:18 Cameron Norman escribió:
> On Thu, Sep 4, 2014 at 4:51 PM, Adam Borowski  wrote:
> > On Thu, Sep 04, 2014 at 02:57:16PM +0200, Margarita Manterola wrote:
> >> On Thu, Sep 4, 2014 at 9:43 AM, envite  wrote:
> >> > Does this Cinnamon for Debian include systemd ?
> >> 
> >> Yes, for Linux it includes systemd.  For kFreeBSD it should be able to
> >> work without systemd, but some packages haven't compiled yet due to
> >> missing dependencies.
> > 
> > If Cinnamon can work without systemd, why is it a hard dependency?
> 
> TL;DR `sudo apt-get install systemd-shim`
> 
> You are mistaken, it is not. What I suspect happened is that something
> depended on logind (libpam-systemd) and libpam-systemd depends on
> "systemd-sysv | systemd-shim". This means that systems will have their
> init system switched even if unneeded unless they predict the issue or
> track down the dependency tree, then learn they have to install
> systemd-shim (which does not exist on Wheezy, so you will have to
> install systemd-sysv then another init after the upgrade). This bug
> has been reported and marked as WONTFIX for reasons that have not been
> fully explained (it is claimed people with init=/lib/systemd/systemd
> in their kcmdline will experience breakage due to systemd-shim
> conflicting with systemd-sysv, however this is actually not likely at
> all according to the shim maintainer).
> 
> Best,
> --
> Cameron Norman

So we are clearly failing to follow the least surprise (for the user) path.

Should not logind depend on systemd-shim | systemd-sysv instead?

Regards

Noel
er Envite


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