Bug#886238: Please introduce official nosystemd build profile

[Lars Wirzenius]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:
> On 1/3/18, Steve Langasek  wrote:
> 
> > Moreover, defining an official nosystemd profile in Debian signals that we
> > are willing to support it, which means any maintainers who refuse such
> > patches will immediately become the targets of abuse from anti-systemd
> > zealots.
> 
> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
> Should I remind your votes in CTTE?
> 
> Please take your Ubuntu employee hat off and speak as DD.

I think you're out of line. Please stop.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Jonathan Dowland]

On Thu, Jan 04, 2018 at 10:25:14PM +0300, Hleb Valoshka wrote:

1) Even Wikipedia knows 43 distributions, much more can be found on
http://without-systemd.org/wiki/index.php/Main_Page#GNU.2FLinux_distributions,
some of them are still Debian based (but migrate to Devuan).


Perhaps these interested parties should be doing the work to spec/design
the build profile changes that are being requested in Debian.


2) Please provide proofs for relationship between MikeeUSA and Devuan
project.


Ansgar does not need to provide proof for this *on debian-devel*. This
has already been covered thoroughly in the distance past on this and
other lists, and is in any case off-topic.


1) Proofs please. DDG & Google find only your words.


As above.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Bug#886238: Please introduce official nosystemd build profile

[Jonathan Dowland]

On Thu, Jan 04, 2018 at 10:44:24PM +0300, Hleb Valoshka wrote:

Do we have runtime systemd detection in all software linked against
libsystemd so it will work properly in absence of systemd? To rebuild
software without libsystemd is the only reliable way to ensure that
non-systemd code pathes are in use.


Whehter something has a systemd code path and whether it links to
libsystemd is orthogonal. As smcv has indicated in another post, the
canonical run-time check for systemd is the existence of
/run/systemd/system. No libsystemd is required for that check and it's
conceivable for software to perform systemd-specific functions without
libsystemd. So, if your motivation is to test non-systemd code paths,
this proposal is *not* sufficient for that purpose.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#886238: marked as done (Please introduce official nosystemd build profile)

[Debian Bug Tracking System]

Your message dated Fri, 5 Jan 2018 11:50:23 +0100
with message-id <20180105105023.r2xpt2ixtoqfa...@shell.thinkmo.de>
and subject line Re: Bug#886238: Please introduce official nosystemd build 
profile
has caused the Debian Bug report #886238,
regarding Please introduce official nosystemd build profile
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist

Please introduce official nosystemd build profile so downstream
distributions can send patches to package maintainers with
systemd-less build instead of keep them in home.
--- End Message ---
--- Begin Message ---
On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote:
> Please introduce official nosystemd build profile so downstream
> distributions can send patches to package maintainers with
> systemd-less build instead of keep them in home.

As you have been already told by several people, Debian supports
systemd-less systems.  If you find bugs running in this mode, please
file bug reports.

Apart from that, I don't see that you managed to describe what a
"nosystemd" profile would actually do.  This would be the least we would
need from such a bug report.

However what I see is, that you and others instead of actually engaging
in discussions just referred to personal attacks.  I and others consider
this unacceptable behaviour on our technical mailing lists and our bug
tracker.  Please be adviced that I will ask both the BTS owner and the
list masters to block you from ever posting again if this behaviour
continues.

As I don't think anything new will come up, I'm closing this bug report.
Don't reopen it, this might just expedite your fate.

Kindly regards,
Bastian

-- 
Most legends have their basis in facts.
-- Kirk, "And The Children Shall Lead", stardate 5029.5--- End Message ---

Re: Bug#886238: Please introduce official nosystemd build profile

[Svante Signell]

On Fri, 2018-01-05 at 01:47 +0100, Adam Borowski wrote:
> 
> 
> Especially you two shouldn't be fighting.  As far as I know, Svante is
> somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
> though), while Marco has a great wealth of udev experience.

Well I did the work an parazyd did commit my patches and issued builds. Question
is: Who did do the real work?

> eudev is currently not needed for Debian, but it's good to have ready and
> tested packages we can import when/if udev becomes systemd only (which can
> happen at any moment as its upstream we don't control).

I really doubt Debian would accept eudev and elogind into their repositories. As
you know Debian is no longer "the Universal Operating System". Next in line of
Debian becoming a truly Linux-only distribution would be to throw out Hurd and
kFreeBSD.

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Fri, Jan 05, 2018 at 12:08:42PM +0100, Svante Signell wrote:
> On Fri, 2018-01-05 at 01:47 +0100, Adam Borowski wrote:
> > Especially you two shouldn't be fighting.  As far as I know, Svante is
> > somewhat involved with eudev maintenance in Devuan (done mostly by parazyd,
> > though), while Marco has a great wealth of udev experience.
> 
> Well I did the work an parazyd did commit my patches and issued builds. 
> Question
> is: Who did do the real work?

Thanks for correction.  I made the blind assumption that the Maintainer:
field has at least some accuracy.  I'm used to Debian workflows, not
Devuan's.

If the whole credit goes to you, good!

> > eudev is currently not needed for Debian, but it's good to have ready and
> > tested packages we can import when/if udev becomes systemd only (which can
> > happen at any moment as its upstream we don't control).
> 
> I really doubt Debian would accept eudev and elogind into their repositories.

Actually, Simon McVittie described a proposal that KatolaZ opined as not
merely acceptable but "a great solution".  It would allow every Debian
package that currently depends on libpam-systemd to be usable on Devuan
without even recompiling, much less a sourceful change -- all while handling
future compat breaks sanely.  I'll see how I can assist.

As for eudev, the only group who can deny a package into the archive are the
ftpmasters, although being useful wrt dependencies is another matter.  If
you think strongly about having such standby package ready, I can sponsor
it into experimental -- on the other hand, unless you can show some benefit,
I strongly would advise against having it in unstable, as it'd complicate
the lives of udev maintainers for no clear gain.  They promised to not make
udev systemd only, and I see no reason for them to renege -- the decision
belongs to a person employed by Red Hat, who could make a future release
require systemd.  If that happens, well, _then_ it'd be time to put eudev
into unstable.


Meow!
-- 
// 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.

Bug#886418: ITP: kwant -- Python package for numerical quantum transport calculations

[Christoph Groth]

Package: wnpp
Severity: wishlist
Owner: Christoph Groth 

* Package name: kwant
  Version : 1.3.2
  Upstream Author : Kwant authors 
* URL : http://www.kwant-project.org/
* License : BSD
  Programming Lang: Python, Cython
  Description : Python package for numerical quantum transport

 Kwant is a Python package for numerical quantum transport
 calculations. It exposes the natural concepts of the theory of quantum
 transport (lattices, symmetries, electrodes, orbital/spin/electron-hole
 degrees of freedom) in a simple and transparent way. Kwant offers direct
 support for calculations of transport properties (conductance, noise,
 scattering matrix), dispersion relations, modes, wave functions, various
 Green’s functions, and out-of-equilibrium local quantities. Other
 computations involving tight-binding Hamiltonians can be implemented
 easily.

Kwant is a scientific library that is popular with condensed matter
physicists.  Since it became public in 2013, Kwant has been used by
researchers around the world in numerous projects that lead to over 180
scientific articles.  In 2017 alone the number of such publications was
80. [1]

I'm one of the main developers of Kwant and have been maintaining
unofficial Debian and Ubuntu packages for it since 2013.  We're
committed to maintain both Kwant and its Debian package for years to
come.  Since I haven't been active in Debian so far, I need a sponsor
for this package.

Kwant depends on tinyarray [2], a Python extension module written in C++
that implements a subset of NumPy that is optimized for very small
arrays.  Tinyarray is fully independent of Kwant, but has seen little use 
outside of Kwant.  Shall I file an ITP for tinyarray as well?

[1] 
http://adsabs.harvard.edu/cgi-bin/nph-ref_history?refs=CITATIONS&bibcode=2014NJPh...16f3065G
[2] https://gitlab.kwant-project.org/kwant/tinyarray

Bug#886238: Please introduce official nosystemd build profile

[Eduard Bloch]

Hallo,
* Johannes Schauer [Wed, Jan 03 2018, 08:24:49PM]:
> > The speculation about a possible nosystemd profile in
> >  is
> > not consistent with that design principle. If a package contains systemd
> > units or uses of libsystemd, then it's safe to assume they were added for a
> > reason. Whether you value that reason or not, it's nearly always true to say
> > that cutting out systemd-related bits is a functional change.
> 
> Cutting out systemd-related bits is probably a functional change in most 
> cases.

It depends. Properly written software which checks for libsystemd-*
stuff at compile time would, in theory, support such polymorphic style
of integration. The question is - how many packages are prepared for
this, and how many upstreams have already moved to "only Linux and only
systemd" style?

I, for one, do still support non-systemd mode in my software (i.e.
upstream hat on) explicitly - but it's not sufficiently tested anymore
and relies on feedback from users from non-Linux worlds. And it requires
additional work, so some upstream developers might be tempted to drop
non-non-systemd support whatsoever.

So my general feeling is that we might add this profile but it is not
something which should be pushed through, at the expense of Debian
maintainers. It would be manpower stolen from us for the benefit of
ideological warriors from the "weird party". Which is something I am not
comfortable with.

Regards,
Eduard.

Re: e2fsprogs as Essential: yes?: Maybe we should be separating l10n files first?

[Manuel A. Fernandez Montecelo]

2018-01-02 03:10 Theodore Ts'o:

My only real concern is whether this might complicate building the
latest version of e2fsprogs for stable and old-stable for
debian-backports.


I think that it's fine, they've been supported for a long time and
stable and old-stable should be covered, not sure about old-old-stable
without backports.


2018-01-03 23:59 Theodore Ts'o:


Would you accept patches to achieve this in e2fsprogs?  It would
probably be quite clean, not complicating/obfuscating the packaging
files too much, usually only 2~10 lines (but I didn't look specifically
into this package yet).


With some help from Simon McVittie, you should be able to use the
build profile pkg.e2fsprogs.no-fuse2fs in the just-uploaded 1.43.8-2
version of e2fsprogs.  It seems to work for me; please let me know if
does what you need.


Not immediately but I will do soon, and possibly send fixes or more
profiles if they're convenient for bootstrapping :)

Thanks, and thanks to Simon too for beating me to it!

--
Manuel A. Fernandez Montecelo 

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon Richter]

Hi,

Am 04.01.2018 um 05:12 schrieb Russ Allbery:

> I think the key to a good path forward is to recognize that systemd solved
> some specific problems, and to build a roadmap of which problems do indeed
> need to be solved and the alternate solutions to them, and which aren't
> important enough to folks who don't like systemd to solve and therefore
> will stay systemd-exclusive features until that changes.  Then there can
> be a sustained ecosystem, with a clear mission, alongside systemd, and
> Debian can endeavor to support both.

We still need a non-systemd ecosystem for everything that is out of
scope for systemd.

I've written a lengthy blog entry[1] about this in 2016. The condensed
argument is that no init system can provide both an imperative and a
descriptive configuration model at the same time unless it solves the
halting problem and resolves the interaction between both configuration
systems. For desktop environments, we need the configuration to be
descriptive and machine writeable, otherwise the configuration dialogs
will not work, but this comes at the price of the flexibility offered by
an imperative language.

Systemd and System V init are two fundamentally different approaches.
Neither can replace the other without breaking core design principles
and becoming completely useless in the process.

   Simon

[1] http://www.simonrichter.eu/blog/2016-03-03-why-sysvinit.html




signature.asc
Description: OpenPGP digital signature