Re: [Dng] Devuan commitments - will trade-off be applied?

[Anto]

On 18/03/15 19:31, Nextime wrote:

Do NOT use apt.devuan.org, the devuan packages are on packages.devuan.org


I don't think all packages are on packages.devuan.org yet as below. But 
please don't worry about that, as I perfectly understand that the work 
on this is still in progress. I brought that up as that triggered me to 
ask the questions about Devuan commitments.


root@v01:~# apt-get update
Hit http://packages.devuan.org jessie InRelease
Hit http://packages.devuan.org jessie/main i386 Packages
Ign http://packages.devuan.org jessie/main Translation-en_US
Ign http://packages.devuan.org jessie/main Translation-en
Reading package lists... Done
root@v01:~#
root@v01:~# apt-cache dumpavail | grep "Package:"
Package: cgmanager
Package: cgmanager-tests
Package: libcgmanager0
Package: libcgmanager-dev
Package: colord
Package: colord-data
Package: gir1.2-colord-1.0
Package: gir1.2-colorhug-1.0
Package: libcolord2
Package: libcolord-dev
Package: libcolorhug2
Package: libcolorhug-dev
Package: debootstrap
Package: devuan-baseconf
Package: devuan-keyring
Package: jenkins-debian-glue
Package: jenkins-debian-glue-buildenv
Package: jenkins-debian-glue-buildenv-git
Package: jenkins-debian-glue-buildenv-lintian
Package: jenkins-debian-glue-buildenv-piuparts
Package: jenkins-debian-glue-buildenv-slave
Package: jenkins-debian-glue-buildenv-svn
Package: jenkins-debian-glue-buildenv-taptools
Package: loginkit
Package: gir1.2-udisks-2.0
Package: libudisks2-0
Package: libudisks2-dev
Package: udisks2
Package: udisks2-doc
Package: bsdutils
Package: libblkid-dev
Package: libmount-dev
Package: libsmartcols-dev
Package: uuid-dev
Package: uuid-runtime
Package: libuuid1
Package: mount
Package: libblkid1
Package: util-linux-locales
Package: libmount1
Package: util-linux
Package: libsmartcols1
root@v01:~#

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Nextime]

On March 18, 2015 6:29:37 PM WET, Joerg Reisenweber  wrote:
>On Wed 18 March 2015 19:07:09 Anto wrote:
>> root@v01:~# apt-cache policy dbus
>> dbus:
>>Installed: 1.8.14-1.0nosystemd1
>>Candidate: 1.8.14-1.0nosystemd1
>>Package pin: 1.8.14-1.0nosystemd1
>>Version table:
>>   1.8.16-1 990
>>  110 http://ftp.debian.org/debian/ jessie/main i386 Packages
>>   *** 1.8.14-1.0nosystemd1 990
>>   -1 http://angband.pl/debian/ nosystemd/main i386 Packages
>>  100 /var/lib/dpkg/status
>>   1.6.8-1+deb7u6 990
>>  800 http://security.debian.org/ wheezy/updates/main i386
>Packages
>>   1.6.8-1+deb7u5 990
>>  700 http://ftp.debian.org/debian/ wheezy/main i386 Packages
>> root@v01:~#
>> root@v01:~# wget 
>> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
>> --2015-03-18 18:16:42-- 
>> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
>> Resolving apt.devuan.org (apt.devuan.org)... 94.23.108.49
>
>...
>
>It seems as if 
>>Installed: 1.8.14-1.0nosystemd1
>>Candidate: 1.8.14-1.0nosystemd1
>is OK (no libsystemd0 dependency), but there's a 
>> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
>in devuan repo which is BAD[TM]
>
>/j
>
>
>
>___
>Dng mailing list
>Dng@lists.dyne.org
>https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Do NOT use apt.devuan.org, the devuan packages are on packages.devuan.org 
-- 
nextime
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Joerg Reisenweber]

On Wed 18 March 2015 19:07:09 Anto wrote:
> root@v01:~# apt-cache policy dbus
> dbus:
>Installed: 1.8.14-1.0nosystemd1
>Candidate: 1.8.14-1.0nosystemd1
>Package pin: 1.8.14-1.0nosystemd1
>Version table:
>   1.8.16-1 990
>  110 http://ftp.debian.org/debian/ jessie/main i386 Packages
>   *** 1.8.14-1.0nosystemd1 990
>   -1 http://angband.pl/debian/ nosystemd/main i386 Packages
>  100 /var/lib/dpkg/status
>   1.6.8-1+deb7u6 990
>  800 http://security.debian.org/ wheezy/updates/main i386 Packages
>   1.6.8-1+deb7u5 990
>  700 http://ftp.debian.org/debian/ wheezy/main i386 Packages
> root@v01:~#
> root@v01:~# wget 
> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
> --2015-03-18 18:16:42-- 
> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
> Resolving apt.devuan.org (apt.devuan.org)... 94.23.108.49

...

It seems as if 
>Installed: 1.8.14-1.0nosystemd1
>Candidate: 1.8.14-1.0nosystemd1
is OK (no libsystemd0 dependency), but there's a 
> http://apt.devuan.org/devuan/pool/main/d/dbus/dbus_1.8.16-1_i386.deb
in devuan repo which is BAD[TM]

/j

signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Anto]

On 18/03/15 15:47, Jude Nelson wrote:
That's very interesting.  Devuan's dbus shouldn't depend on 
libsystemd0 at all (it builds and runs without it); if it is pulling 
in libsystemd0 as a dependency, then there's a bug in our dbus package.


Can you show me the output of:

$ aptitude show dbus
$ apt-cache rdepends dbus

Also, if it is convenient, can you download (but not install) dbus, 
extract the package, and run "ldd" on dbus-daemon to see whether or 
not the binary accidentally got compiled to link against libsystemd0?


Thanks,
Jude



Hello Jude,

I am not sure what you are trying to understand. I think "aptitude show 
dbus" only provides the information on dbus package that is currently 
installed. As I am using dbus package from http://angband.pl/debian/, 
which clearly does not have dependency to libsystemd0, so the result is 
not as you expected. Anyway, I collected the outputs that might be 
relevant, a part from "apt-cache rdepends dbus" as this one provides the 
list of packages that depend on dbus so I got a long list and none of 
them is libsystemd0. I think the output of "ldd usr/bin/dbus-daemon" 
below confirmed that dbus package on Devuan repository requires libsystemd0.


Based on the my experience so far in fighting to remove systemd 
components from Debian, I think the easiest and certain way to know the 
dependency that comes from the repository that we pull in is by running 
"apt-get -u dist-upgrade" and hit "n", then manually check why systemd 
components are being pulled by running "apt-cache depends packages>".


Kind regards,

Anto


folder>


root@v01:~# apt-get update
Hit http://apt.devuan.org jessie InRelease
Hit http://apt.devuan.org jessie/main i386 Packages
Ign http://apt.devuan.org jessie/main Translation-en_US
Ign http://apt.devuan.org jessie/main Translation-en
Reading package lists... Done
root@v01:~#
root@v01:~# aptitude show dbus
Package: dbus
State: installed
Automatically installed: no
Multi-Arch: foreign
Version: 1.8.14-1.0nosystemd1
Priority: standard
Section: admin
Maintainer: Utopia Maintenance Team 


Architecture: i386
Uncompressed Size: 1,034 k
Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.17), libcap-ng0, 
libdbus-1-3 (>= 1.7.6), libexpat1 (>= 2.0.1), libselinux1 (>= 2.0.65), 
adduser, lsb-base (>= 3.2-14)

Suggests: dbus-x11
Description: simple interprocess messaging system (daemon and utilities)

Homepage: http://dbus.freedesktop.org/

Tags: devel::rpc, implemented-in::c, interface::daemon, protocol::TODO, 
role::program


root@v01:~#
root@v01:~# apt-cache policy dbus
dbus:
  Installed: 1.8.14-1.0nosystemd1
  Candidate: 1.8.16-1
  Version table:
 1.8.16-1 0
500 http://apt.devuan.org/devuan/ jessie/main i386 Packages
 *** 1.8.14-1.0nosystemd1 0
100 /var/lib/dpkg/status
root@v01:~#

/etc/apt/preferences.d folder>


root@v01:~# apt-get update
Ign http://ftp.debian.org wheezy InRelease
Get:1 http://ftp.debian.org wheezy-backports InRelease [148 kB]
Get:2 http://security.debian.org wheezy/updates InRelease [103 kB]
Get:3 http://ftp.debian.org jessie InRelease [199 kB]
Get:4 http://angband.pl nosystemd InRelease [6,932 B]
Get:5 http://ftp.debian.org wheezy Release.gpg [1,655 B]
Get:6 http://ftp.debian.org wheezy Release [168 kB]
Get:7 http://security.debian.org wheezy/updates/main i386 Packages [273 kB]
Get:8 http://angband.pl nosystemd/main i386 Packages [27.8 kB]
Get:9 http://security.debian.org wheezy/updates/main Translation-en [154 kB]
Get:10 http://ftp.debian.org wheezy-backports/main i386 Packages [554 kB]
Get:11 http://ftp.debian.org wheezy-backports/main Translation-en [354 kB]
Get:12 http://ftp.debian.org jessie/main Translation-en [4,599 kB]
Ign http://angband.pl nosystemd/main Translation-en_US
Ign http://angband.pl nosystemd/main Translation-en
Get:13 http://ftp.debian.org wheezy/main i386 Packages [5,859 kB]
Get:14 http://ftp.debian.org wheezy/main Translation-en [3,848 kB]
Get:15 http://ftp.debian.org jessie/main i386 Packages [6,786 kB]
Fetched 23.1 MB in 15s (1,446 kB/s)
Reading package lists... Done
root@v01:~#
root@v01:~# aptitude show dbus
Package: dbus
State: installed
Automatically installed: no
Multi-Arch: foreign
Version: 1.8.14-1.0nosystemd1
Priority: standard
Section: admin
Maintainer: Utopia Maintenance Team 


Architecture: i386
Uncompressed Size: 1,034 k
Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.17), libcap-ng0, 
libdbus-1-3 (>= 1.7.6), libexpat1 (>= 2.0.1), libselinux1 (>= 2.0.65), 
adduser, lsb-base (>= 3.2-14)

Suggests: dbus-x11
Description: simple interprocess messaging system (daemon and utilities)
 D-Bus is a message bus, used for sending messages between 
applications. Conceptually, it fits somewhere in between raw sockets and 
CORBA in terms of complexity.


 D-Bus supports broadcast messages, asynchronous messages (thus 
decreasing latency), authentication, and more. It is designed to be 
low-overhead; messages are sent using a binary protocol,
 not using XML. D-Bus also supports a method call m

Re: [Dng] vdev status updates

[Nate Bargmann]

* On 2015 18 Mar 10:40 -0500, Joerg Reisenweber wrote:
> Sounds all very clean and nice.
> Kudos to Jude! Looking forward to using vdev* eventually

Seconded.  Thanks for your work the past several weeks, Jude.  Good to
have you aboard.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] vdev status updates

[Didier Kryn]

Le 18/03/2015 16:37, Joerg Reisenweber a écrit :

Sounds all very clean and nice.
Kudos to Jude! Looking forward to using vdev* eventually

/j


+1 :-)Didier




On Wed 18 March 2015 10:43:06 Jude Nelson wrote:

Hi Didier,


It's very good to use inotify, because it's a standard Linux tool (don't

know for other nixes), not yet-another-interface. This way DEs shouldn't
have any concern implementing it.

That's the plan :)  Like udisks2, NetworkManager, and upower, vdevd-user
(or something like it) offer DEs the ability to have their DE-specific
device-handling programs executed when a device gets plugged in or pulled
out.

inotify is Linux-specific, kqueue is BSD-specific, and /dev/poll is
Solaris-specific.  However, libkqueue ports the BSD kqueue interface to
Linux and Solaris, so using that library as a way to watch /dev for changes
would let vdevd-user be portable (i.e. the Linux port of libkqueue is
implemented with inotify(2)).


This means you will provide support for inotify in vdevfs? AFAIK there

isn't in every filesystem, eg sysfs.

Interestingly, inotify(2) is implemented by the kernel's VFS, not the
filesystem implementation (this is true for FUSE as well).  The only way
the VFS learns when files and directories change is when a userspace
program makes a VFS syscall.  This is why you can't use inotify(2) to watch
procfs and sysfs for changes--the changes to the kernel state these
filesystems represent are not routed through the VFS layer.

This isn't a problem for vdev, since vdevd makes the VFS syscalls--it's
vdevd that actually triggers the inotify(2) events, not vdevfs.  This means
you don't need to use vdevfs for vdevd-user to work--inotify(2) will work
regardless of whatever filesystem /dev resides on.

-Jude

On Wed, Mar 18, 2015 at 6:01 AM, Didier Kryn  wrote:

 It's very good to use inotify, because it's a standard Linux tool

(don't know for other nixes), not yet-another-interface. This way DEs
shouldn't have any concern implementing it.

 This means you will provide support for inotify in vdevfs? AFAIK there

isn't in every filesystem, eg sysfs.

 Didier

Le 17/03/2015 09:48, Jude Nelson a écrit :

How would that "watching" work?

vdevd-user would have an inotify(2)-based back-end (hopefully via
libkqueue, so it would be portable).  The back-end would set up inotify
watches on /dev and its descendant directories, and translate creat(2)
and
unlink(2) events from inotify into a vdev-specific device event with the
relevant information (e.g. by querying the device metadata that the
system's vdevd puts into /dev/vdev/...).

-Jude

On Tue, Mar 17, 2015 at 1:30 AM, Joerg Reisenweber mailto:reisenwe...@web.de>> wrote:
 On Tue 17 March 2015 01:20:43 Jude Nelson wrote:
 > What I'm considering doing is creating vdevd-user, a build of
 > vdevd with a backend for watching the contents of /dev, instead of
 > listening to the kernel for device events.
 
 How would that "watching" work?
 
 /jOERG

 ___
 Dng mailing list
 Dng@lists.dyne.org 
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] vdev status updates

[Joerg Reisenweber]

Sounds all very clean and nice.
Kudos to Jude! Looking forward to using vdev* eventually

/j


On Wed 18 March 2015 10:43:06 Jude Nelson wrote:
> Hi Didier,
> 
> > It's very good to use inotify, because it's a standard Linux tool (don't
> 
> know for other nixes), not yet-another-interface. This way DEs shouldn't
> have any concern implementing it.
> 
> That's the plan :)  Like udisks2, NetworkManager, and upower, vdevd-user
> (or something like it) offer DEs the ability to have their DE-specific
> device-handling programs executed when a device gets plugged in or pulled
> out.
> 
> inotify is Linux-specific, kqueue is BSD-specific, and /dev/poll is
> Solaris-specific.  However, libkqueue ports the BSD kqueue interface to
> Linux and Solaris, so using that library as a way to watch /dev for changes
> would let vdevd-user be portable (i.e. the Linux port of libkqueue is
> implemented with inotify(2)).
> 
> > This means you will provide support for inotify in vdevfs? AFAIK there
> 
> isn't in every filesystem, eg sysfs.
> 
> Interestingly, inotify(2) is implemented by the kernel's VFS, not the
> filesystem implementation (this is true for FUSE as well).  The only way
> the VFS learns when files and directories change is when a userspace
> program makes a VFS syscall.  This is why you can't use inotify(2) to watch
> procfs and sysfs for changes--the changes to the kernel state these
> filesystems represent are not routed through the VFS layer.
> 
> This isn't a problem for vdev, since vdevd makes the VFS syscalls--it's
> vdevd that actually triggers the inotify(2) events, not vdevfs.  This means
> you don't need to use vdevfs for vdevd-user to work--inotify(2) will work
> regardless of whatever filesystem /dev resides on.
> 
> -Jude
> 
> On Wed, Mar 18, 2015 at 6:01 AM, Didier Kryn  wrote:
> > It's very good to use inotify, because it's a standard Linux tool
> > 
> > (don't know for other nixes), not yet-another-interface. This way DEs
> > shouldn't have any concern implementing it.
> > 
> > This means you will provide support for inotify in vdevfs? AFAIK there
> > 
> > isn't in every filesystem, eg sysfs.
> > 
> > Didier
> > 
> > Le 17/03/2015 09:48, Jude Nelson a écrit :
> >> > How would that "watching" work?
> >> 
> >> vdevd-user would have an inotify(2)-based back-end (hopefully via
> >> libkqueue, so it would be portable).  The back-end would set up inotify
> >> watches on /dev and its descendant directories, and translate creat(2)
> >> and
> >> unlink(2) events from inotify into a vdev-specific device event with the
> >> relevant information (e.g. by querying the device metadata that the
> >> system's vdevd puts into /dev/vdev/...).
> >> 
> >> -Jude
> >> 
> >> On Tue, Mar 17, 2015 at 1:30 AM, Joerg Reisenweber  >> 
> >> > wrote:
> >> On Tue 17 March 2015 01:20:43 Jude Nelson wrote:
> >> > What I'm considering doing is creating vdevd-user, a build of
> >> > vdevd with a backend for watching the contents of /dev, instead of
> >> > listening to the kernel for device events.
> >> 
> >> How would that "watching" work?
> >> 
> >> /jOERG
> >> ___
> >> Dng mailing list
> >> Dng@lists.dyne.org 
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >> 
> >> ___
> >> Dng mailing list
> >> Dng@lists.dyne.org
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> > 
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


signature.asc
Description: This is a digitally signed message part.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greetings & how to help

[hellekin]

On 03/18/15 10:56, Udo Rader wrote:
> Haven't tried it for myself, but the Wiki says there are native qemu
> images as well:
> 
> https://git.devuan.org/devuan/devuan-project/wikis/try-devuan-on-qemu
>
*** This was the first pre-alpha release and to my knowledge has not
been updated since.  The Vagrant image is almost up-to-date.  Jaromil
said he will add support for qemu (at least) in the next bake.

If you can't wait, you may try doing it yourself using the devuan-sdk.
https://git.devuan.org/devuan/devuan-sdk

==
hk

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greetings & how to help

[Linuxito]

Thank you!

On Wed, Mar 18, 2015 at 10:56 AM, Udo Rader  wrote:

> Haven't tried it for myself, but the Wiki says there are native qemu
> images as well:
>
> https://git.devuan.org/devuan/devuan-project/wikis/try-devuan-on-qemu
>
> On 03/18/2015 02:48 PM, Linuxito wrote:
> > How can you download the image without using vagrant? I couldn't make it
> > work on my FBSD box :(
> >
> > On Tue, Mar 17, 2015 at 7:06 PM, fsmithred  > > wrote:
> >
> > On 03/17/2015 09:56 AM, Steve Litt wrote:
> > > I tried the Vagrant on my Wheezy box the day the Vagrant image
> came out,
> > > and it errored out with some VirtualBox error. I forgot the error,
> and
> > > don't have enough time to whip it into working shape. Are there any
> > > instructions for using Vagrant with Qemu instead of Virtualbox?
> > >
> >
> >
> > If you managed to download the image...
> >
> >   qemu-img convert -f vmdk -O raw box-disk1.vmdk devuan_alpha1.img
> >
> > fsr
> >
> >
> >
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org 
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> >
> >
> >
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Steve Litt]

On Tue, 17 Mar 2015 21:00:49 +0100
Anto  wrote:

 
> Will Devuan be really free from systemd and its components? Or will 
> there be trade-off being applied so that some of systemd components
> will be used in Devuan?

Of course, I can't answer authoritatively, because my only role in the
project is documentation. But I *can* tell you about the couple months
during which I did the Manjaro Experiments.

With the Manjaro Experiments, getting rid of systemd was a journey, not
an event. The first thing I did was simply init with a different init
system (openrc, runit and Epoch). At that point, every silly systemd
helper system was intact and used. Then slowly I began to replace those
things. One by one, I pretty much replaced everything except udev.

And of course, my Manjaro Experiments were much less challenging than
Devuan's ultimate goal. I supported only LXDE and Openbox. I didn't
need to support LVM or encription or even non-default disk partitioning
or GUID support. A lot of what I did was, if user software needed a
systemd dependency, I just got rid of that user software. Except for
Gnome, Devuan can't do that.

>From my Manjaro Experiments experience, I would be neither surprised nor
dissapointed if the first beta release of Devuan had some remaining
systemd'isms. It's a step, in the right direction, on the journey
toward complete independence from all things systemd.

I'd also like to point out that the perfect is the enemy of the good. I
fear that if we hold back release until every systemd'ism is gone,
we'll never release. And the fact is, forever, Red Hat and their
poetterproxy will be inserting new infections that can be removed, but
not instantaneously.

In summary, my personal opinion is 100% depoetterization is something
we're working toward, but it's better not to let that hold back our
releases, always assuming we're going in the right direction, which we
most certainly are right now.

SteveT

Steve Litt*  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Jude Nelson]

That's very interesting.  Devuan's dbus shouldn't depend on libsystemd0 at
all (it builds and runs without it); if it is pulling in libsystemd0 as a
dependency, then there's a bug in our dbus package.

Can you show me the output of:

$ aptitude show dbus
$ apt-cache rdepends dbus

Also, if it is convenient, can you download (but not install) dbus, extract
the package, and run "ldd" on dbus-daemon to see whether or not the binary
accidentally got compiled to link against libsystemd0?

Thanks,
Jude

On Wed, Mar 18, 2015 at 3:33 AM, Anto  wrote:

> On 18/03/15 00:56, Jude Nelson wrote:
>
>> Hi Anto,
>>
>> I think the plan is to make the installation of all systemd components
>> optional.  The packages in git.devuan.org that
>> are cloned from Debian's sources have build flags set automatically to
>> compile out systemd dependencies, for example.
>>
>> If you're wondering what's pulling in libsystemd0 in your above example,
>> you could run "aptitude why libsystemd0" to find out what's pulling it in.
>> If it's a package in Devuan pulling it in, please let us know!
>>
>> -Jude
>>
>
> Hello Jude,
>
> I don't think "aptitude why libsystemd0" provide reliable information
> about the package dependency. It shows indeed which package depends on
> other package, but it checks the list on the repository instead of the ones
> that are going to be installed and upgraded. As you can see below,
> "knot-libs" depends on libsystemd0 but it is not on the list of the
> packages that are going to be installed or upgraded.
>
> root@v01:/etc/apt# apt-get update
> Get:1 http://apt.devuan.org jessie InRelease [13.3 kB]
> Get:2 http://apt.devuan.org jessie/main i386 Packages [8,251 kB]
> Ign http://apt.devuan.org jessie/main Translation-en_US
> Ign http://apt.devuan.org jessie/main Translation-en
> Fetched 8,264 kB in 6s (1,319 kB/s)
> Reading package lists... Done
> root@v01:/etc/apt#
> root@v01:/etc/apt# apt-get -u dist-upgrade
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Calculating upgrade... The following packages were automatically installed
> and are no longer required:
>   libgd2-xpm libice6 libmagickcore5 libmagickwand5 libsm6 libxt6 x11-common
> Use 'apt-get autoremove' to remove them.
> Done
> The following NEW packages will be installed:
>   init-system-helpers libapparmor1 libestr0 libfftw3-double3 libjson-c2
> liblogging-stdlog0 liblognorm1 libmagickcore-6.q16-2 libmagickwand-6.q16-2
> libsystemd0 libudev1 openssh-sftp-server
>   php5-json startpar
> The following packages will be upgraded:
>   anacron at bsdutils consolekit cron dbus dmsetup dpkg dpkg-dev
> initscripts libck-connector0 libdbus-glib-1-2 libdevmapper1.02.1
> libdpkg-perl libgnutls-deb0-28 libgnutls-openssl27
>   libpam-ck-connector libpolkit-gobject-1-0 logrotate openssh-client
> openssh-server php5-cli php5-common php5-fpm php5-gd php5-imagick
> php5-sqlite rsyslog ssh sysv-rc sysvinit
>   sysvinit-utils udev uuid-runtime
> 34 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
> Need to get 19.5 MB of archives.
> After this operation, 21.2 MB of additional disk space will be used.
> Do you want to continue? [Y/n] n
> Abort.
> root@v01:/etc/apt#
> root@v01:/etc/apt# aptitude why libsystemd0
> p   knot-dnsutils Provides dnsutils
> p   knot-dnsutils Depends  knot-libs (= 1.6.0-1)
> p   knot-libs Depends  libsystemd0
> root@v01:/etc/apt#
>
> I usually check the package dependency using "apt-cache depends".
>
> Amongst the packages that are going be installed and upgraded, only the
> following 3 packages directly depend on libsystemd0:
>
> - dbus
> - libpolkit-gobject-1-0 (required by consolekit)
> - php5-fpm
>
> I am quite sure that those packages were pulled from Devuan repository as
> it is the only repository on my source.list.
>
> If I may ask to request, I would prefer "init-system-helpers" to be
> excluded from the dependency of all packages because it is clearly the
> helper for systemd init only. So it should not be in Devuan if Devuan would
> not provide systemd init (which I really hope would be the case).
>
> The following packages from the above list directly depend on
> init-system-helpers:
>
> - anacron
> - at
> - cron
> - openssh-server
> - php5-fpm
> - rsyslog
>
> Kind regards,
>
> Anto
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] vdev status updates

[Jude Nelson]

Hi Didier,

> It's very good to use inotify, because it's a standard Linux tool (don't
know for other nixes), not yet-another-interface. This way DEs shouldn't
have any concern implementing it.

That's the plan :)  Like udisks2, NetworkManager, and upower, vdevd-user
(or something like it) offer DEs the ability to have their DE-specific
device-handling programs executed when a device gets plugged in or pulled
out.

inotify is Linux-specific, kqueue is BSD-specific, and /dev/poll is
Solaris-specific.  However, libkqueue ports the BSD kqueue interface to
Linux and Solaris, so using that library as a way to watch /dev for changes
would let vdevd-user be portable (i.e. the Linux port of libkqueue is
implemented with inotify(2)).

> This means you will provide support for inotify in vdevfs? AFAIK there
isn't in every filesystem, eg sysfs.

Interestingly, inotify(2) is implemented by the kernel's VFS, not the
filesystem implementation (this is true for FUSE as well).  The only way
the VFS learns when files and directories change is when a userspace
program makes a VFS syscall.  This is why you can't use inotify(2) to watch
procfs and sysfs for changes--the changes to the kernel state these
filesystems represent are not routed through the VFS layer.

This isn't a problem for vdev, since vdevd makes the VFS syscalls--it's
vdevd that actually triggers the inotify(2) events, not vdevfs.  This means
you don't need to use vdevfs for vdevd-user to work--inotify(2) will work
regardless of whatever filesystem /dev resides on.

-Jude

On Wed, Mar 18, 2015 at 6:01 AM, Didier Kryn  wrote:

> It's very good to use inotify, because it's a standard Linux tool
> (don't know for other nixes), not yet-another-interface. This way DEs
> shouldn't have any concern implementing it.
>
> This means you will provide support for inotify in vdevfs? AFAIK there
> isn't in every filesystem, eg sysfs.
>
> Didier
>
> Le 17/03/2015 09:48, Jude Nelson a écrit :
>
>> > How would that "watching" work?
>>
>> vdevd-user would have an inotify(2)-based back-end (hopefully via
>> libkqueue, so it would be portable).  The back-end would set up inotify
>> watches on /dev and its descendant directories, and translate creat(2) and
>> unlink(2) events from inotify into a vdev-specific device event with the
>> relevant information (e.g. by querying the device metadata that the
>> system's vdevd puts into /dev/vdev/...).
>>
>> -Jude
>>
>> On Tue, Mar 17, 2015 at 1:30 AM, Joerg Reisenweber > > wrote:
>>
>> On Tue 17 March 2015 01:20:43 Jude Nelson wrote:
>> > What I'm considering doing is creating vdevd-user, a build of
>> > vdevd with a backend for watching the contents of /dev, instead of
>> > listening to the kernel for device events.
>>
>> How would that "watching" work?
>>
>> /jOERG
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org 
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>>
>>
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greetings & how to help

[Udo Rader]

Haven't tried it for myself, but the Wiki says there are native qemu
images as well:

https://git.devuan.org/devuan/devuan-project/wikis/try-devuan-on-qemu

On 03/18/2015 02:48 PM, Linuxito wrote:
> How can you download the image without using vagrant? I couldn't make it
> work on my FBSD box :(
> 
> On Tue, Mar 17, 2015 at 7:06 PM, fsmithred  > wrote:
> 
> On 03/17/2015 09:56 AM, Steve Litt wrote:
> > I tried the Vagrant on my Wheezy box the day the Vagrant image came out,
> > and it errored out with some VirtualBox error. I forgot the error, and
> > don't have enough time to whip it into working shape. Are there any
> > instructions for using Vagrant with Qemu instead of Virtualbox?
> >
> 
> 
> If you managed to download the image...
> 
>   qemu-img convert -f vmdk -O raw box-disk1.vmdk devuan_alpha1.img
> 
> fsr
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org 
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> 
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greetings & how to help

[Linuxito]

How can you download the image without using vagrant? I couldn't make it
work on my FBSD box :(

On Tue, Mar 17, 2015 at 7:06 PM, fsmithred  wrote:

> On 03/17/2015 09:56 AM, Steve Litt wrote:
> > I tried the Vagrant on my Wheezy box the day the Vagrant image came out,
> > and it errored out with some VirtualBox error. I forgot the error, and
> > don't have enough time to whip it into working shape. Are there any
> > instructions for using Vagrant with Qemu instead of Virtualbox?
> >
>
>
> If you managed to download the image...
>
>   qemu-img convert -f vmdk -O raw box-disk1.vmdk devuan_alpha1.img
>
> fsr
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] vdev status updates

[Didier Kryn]

It's very good to use inotify, because it's a standard Linux tool 
(don't know for other nixes), not yet-another-interface. This way DEs 
shouldn't have any concern implementing it.


This means you will provide support for inotify in vdevfs? AFAIK 
there isn't in every filesystem, eg sysfs.


Didier

Le 17/03/2015 09:48, Jude Nelson a écrit :

> How would that "watching" work?

vdevd-user would have an inotify(2)-based back-end (hopefully via 
libkqueue, so it would be portable).  The back-end would set up 
inotify watches on /dev and its descendant directories, and translate 
creat(2) and unlink(2) events from inotify into a vdev-specific device 
event with the relevant information (e.g. by querying the device 
metadata that the system's vdevd puts into /dev/vdev/...).


-Jude

On Tue, Mar 17, 2015 at 1:30 AM, Joerg Reisenweber > wrote:


On Tue 17 March 2015 01:20:43 Jude Nelson wrote:
> What I'm considering doing is creating vdevd-user, a build of
> vdevd with a backend for watching the contents of /dev, instead of
> listening to the kernel for device events.

How would that "watching" work?

/jOERG
___
Dng mailing list
Dng@lists.dyne.org 
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng




___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] greetings & how to help

[Udo Rader]

Hi Jude,

thanks for the bunch of information, especially the various project
links, this brings some light to my questions.

To get a feeling about the status quo, I will start playing with the
vagrant image and then be back here.

For the infrastructure things, I will follow up directly in gitlab.

Regards

Udo

On 03/16/2015 11:30 PM, Jude Nelson wrote:
> Hi Udo,
> 
> I'm not part of the VUA, and what I'm about to say is by no means
> comprehensive or official.
> 
> I'd say things are looking up for Devuan:
> * The Devuan package repository is available at
> http://apt.devuan.org/devuan.  I think the current plan is to mirror
> Debian's repositories and copy in Devuan's systemd-free variants (i.e.
> for util-linux, dbus, etc.).
> * There's an i386 Vagrant image released for pre-alpha testing
> (see 
> https://git.devuan.org/devuan/devuan-project/wikis/try-devuan-on-vagrant).
> * There's a Devuan SDK available that lets you build Devuan installer
> ISOs in a fairly straight-forward manner, as well as manage builds of
> Devuan-specific packages.
> 
> Also, I think a lot of the development conversation has moved to IRC. 
> The logs are at https://botbot.me/freenode/devuan/
> 
> There are also some interesting projects aimed at building long-term
> replacements for systemd components:
> * LoginKit (replaces systemd-logind).
>  https://git.devuan.org/pkgs-utopia-substitution/loginkit
> * libsysdev (replaces libudev).  https://github.com/idunham/libsysdev
> * vdev (replaces udevd).  https://github.com/jcnelson/vdev  (DISCLAIMER:
> I'm the author)
> 
> Insofar as what needs doing, there's a pre-alpha ISO floating around
> (Valentine pre-alpha), and the Vagrant image could always use more
> testing and bug reports.  There's also a list of infrastructure to-dos
> here: https://git.devuan.org/devuan-infrastructure/todo/issues.
> 
> Hope this helps,
> -Jude
> 
> 
> On Sun, Mar 15, 2015 at 8:54 AM, Udo Rader  > wrote:
> 
> Hi,
> 
> short preface: the idea of systemd running on our ~100 servers causes me
> more than serious headache and so, like many others, I am interested in
> having a viable alternative to this madness.
> 
> Unfortunately I was not very successful finding out how Devuan is doing
> - despite having done my homework digging both through the website and
> the ML archives. The best I came up with is the announcement of a spring
> (alpha?) release.
> 
> I am not asking the evil "when will it be done" question, instead I am
> asking how I could possibly help to get things going :)
> 
> You could very likely call me a Linux veteran with almost 20 years
> playing the game and in a (now very remote) past I even did some
> packaging for Mandriva. For the past 10 years almost every server we
> have been provisioning is based on Debian and so I know that beast quite
> well, but I have never been involved with Debian as an organization.
> 
> My daily job is devops oriented, with the dev side focusing mostly on
> Java and the ops side planning and partially maintaining our
> infrastructure.
> 
> So what are the areas that require additional help?
> 
> Regards
> 
> Udo
> ___
> Dng mailing list
> Dng@lists.dyne.org 
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 
> 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Systemd: it depends -- was Re: release date

[Anto]

On 18/03/15 01:06, hellekin wrote:

Devuan provides free init, letting the user choose which init system
they want to use.  Obviously, because the primary job is to remove the
mandatory dependency on systemd, if you choose to run systemd, you'd
better stick with Debian.  Now if you want to run standard GNU utilities
to do what systemd wants to replace beyond init, you're in the right place.


My main intention to move out of Debian is not to have systemd including 
all of its components. So I really hope that Devuan will not make any 
trade-off about using any systemd components at all as we will end up 
running in circle later on.



There are a couple of systemd components whose dependency is harder to
remove, such as logind and udevd, especially for the GNOME desktop that
highly integrates with systemd.  Work is currently being done to replace
them or at least provide a systemd shim that would allow developers to
keep working on a compatible layer without the need for any systemd
components.


On my notebook that I am using writing this email, I use important 
packages from "deb http://angband.pl/debian/ nosystemd main" as below. I 
believe that is the repository of Adam Borowski. Perhaps you just could 
re-package the source code from there for Devuan. And perhaps we could 
avoid using any GNOME components on the initial release, for instance 
just support XFCE desktop first.


root@hp8530w:/home/anto# dpkg -l | grep nosystemd
ii  bsdutils 1:2.25.2-5.0nosystemd1 amd64basic 
utilities from 4.4BSD-Lite
ii  dbus 1.8.16-1.0nosystemd1   amd64simple 
interprocess messaging system (daemon and utilities)
ii  dbus-x11 1.8.16-1.0nosystemd1   amd64simple 
interprocess messaging system (X11 deps)
ii  gvfs:amd64 1.22.2-1.0nosystemd1   amd64userspace 
virtual filesystem - GIO module
ii  gvfs-common 1.22.2-1.0nosystemd1   all  
userspace virtual filesystem - common data files
ii  gvfs-daemons 1.22.2-1.0nosystemd1   amd64
userspace virtual filesystem - servers
ii  gvfs-libs:amd64 1.22.2-1.0nosystemd1   amd64
userspace virtual filesystem - private libraries
ii  init 1.22+nosystemd1amd64System-V-like 
init utilities - metapackage
ii  libblkid1:amd64 2.25.2-5.0nosystemd1   amd64
block device id library
ii  libcolord2:amd64 1.2.1-1.0nosystemd1amd64
system service to manage device colour profiles -- runtime
ii  libdbus-1-3:amd64 1.8.16-1.0nosystemd1   amd64
simple interprocess messaging system (library)
ii  libmount1:amd64 2.25.2-5.0nosystemd1   amd64
device mounting library
ii  libpolkit-agent-1-0:amd64 0.105-8.0nosystemd1
amd64PolicyKit Authentication Agent API
ii  libpolkit-backend-1-0:amd64 0.105-8.0nosystemd1
amd64PolicyKit backend API
ii  libpolkit-gobject-1-0:amd64 0.105-8.0nosystemd1
amd64PolicyKit Authorization API
ii  libpulse0:amd64 5.0-13.0nosystemd1 amd64
PulseAudio client libraries
ii  libsmartcols1:amd64 2.25.2-5.0nosystemd1   amd64
smart column output alignment library
ii  libudisks2-0:amd64 2.1.3-5.0nosystemd1amd64
GObject based library to access udisks2
ii  libupower-glib1:amd64 0.99.1-really-0.9.23-2.0nosystemd1 
amd64abstraction for power management - shared library
ii  libuuid1:amd64 2.25.2-5.0nosystemd1   amd64
Universally Unique ID library
ii  mount 2.25.2-5.0nosystemd1   amd64Tools for 
mounting and manipulating filesystems
ii  policykit-1 0.105-8.0nosystemd1amd64
framework for managing administrative policies and privileges
ii  udisks2 2.1.3-5.0nosystemd1amd64D-Bus 
service to access and manipulate storage devices
ii  upower 0.99.1-really-0.9.23-2.0nosystemd1 amd64abstraction 
for power management
ii  util-linux 2.25.2-5.0nosystemd1   amd64
Miscellaneous system utilities
ii  util-linux-locales 2.25.2-5.0nosystemd1   all  
Locales files for util-linux
ii  xfce4-power-manager 1.4.1-2.0nosystemd1amd64
power manager for Xfce desktop
ii  xfce4-power-manager-data 1.4.1-2.0nosystemd1
all  power manager for Xfce desktop, arch-indep files
ii  xfce4-power-manager-plugins 1.4.1-2.0nosystemd1
amd64power manager plugins for Xfce panel

root@hp8530w:/home/anto#

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [Dng] Devuan commitments - will trade-off be applied?

[Anto]

On 18/03/15 00:56, Jude Nelson wrote:

Hi Anto,

I think the plan is to make the installation of all systemd components 
optional.  The packages in git.devuan.org that 
are cloned from Debian's sources have build flags set automatically to 
compile out systemd dependencies, for example.


If you're wondering what's pulling in libsystemd0 in your above 
example, you could run "aptitude why libsystemd0" to find out what's 
pulling it in.  If it's a package in Devuan pulling it in, please let 
us know!


-Jude


Hello Jude,

I don't think "aptitude why libsystemd0" provide reliable information 
about the package dependency. It shows indeed which package depends on 
other package, but it checks the list on the repository instead of the 
ones that are going to be installed and upgraded. As you can see below, 
"knot-libs" depends on libsystemd0 but it is not on the list of the 
packages that are going to be installed or upgraded.


root@v01:/etc/apt# apt-get update
Get:1 http://apt.devuan.org jessie InRelease [13.3 kB]
Get:2 http://apt.devuan.org jessie/main i386 Packages [8,251 kB]
Ign http://apt.devuan.org jessie/main Translation-en_US
Ign http://apt.devuan.org jessie/main Translation-en
Fetched 8,264 kB in 6s (1,319 kB/s)
Reading package lists... Done
root@v01:/etc/apt#
root@v01:/etc/apt# apt-get -u dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... The following packages were automatically 
installed and are no longer required:

  libgd2-xpm libice6 libmagickcore5 libmagickwand5 libsm6 libxt6 x11-common
Use 'apt-get autoremove' to remove them.
Done
The following NEW packages will be installed:
  init-system-helpers libapparmor1 libestr0 libfftw3-double3 libjson-c2 
liblogging-stdlog0 liblognorm1 libmagickcore-6.q16-2 
libmagickwand-6.q16-2 libsystemd0 libudev1 openssh-sftp-server

  php5-json startpar
The following packages will be upgraded:
  anacron at bsdutils consolekit cron dbus dmsetup dpkg dpkg-dev 
initscripts libck-connector0 libdbus-glib-1-2 libdevmapper1.02.1 
libdpkg-perl libgnutls-deb0-28 libgnutls-openssl27
  libpam-ck-connector libpolkit-gobject-1-0 logrotate openssh-client 
openssh-server php5-cli php5-common php5-fpm php5-gd php5-imagick 
php5-sqlite rsyslog ssh sysv-rc sysvinit

  sysvinit-utils udev uuid-runtime
34 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 19.5 MB of archives.
After this operation, 21.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
root@v01:/etc/apt#
root@v01:/etc/apt# aptitude why libsystemd0
p   knot-dnsutils Provides dnsutils
p   knot-dnsutils Depends  knot-libs (= 1.6.0-1)
p   knot-libs Depends  libsystemd0
root@v01:/etc/apt#

I usually check the package dependency using "apt-cache depends".

Amongst the packages that are going be installed and upgraded, only the 
following 3 packages directly depend on libsystemd0:


- dbus
- libpolkit-gobject-1-0 (required by consolekit)
- php5-fpm

I am quite sure that those packages were pulled from Devuan repository 
as it is the only repository on my source.list.


If I may ask to request, I would prefer "init-system-helpers" to be 
excluded from the dependency of all packages because it is clearly the 
helper for systemd init only. So it should not be in Devuan if Devuan 
would not provide systemd init (which I really hope would be the case).


The following packages from the above list directly depend on 
init-system-helpers:


- anacron
- at
- cron
- openssh-server
- php5-fpm
- rsyslog

Kind regards,

Anto

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng