Re: [Dng] stonix

2015-05-14 Thread Jaromil
dear Roy,

On 13 May 2015 18:33:44 CEST, Roy Nielsen  wrote:

>We released a (beta) security tool to give non-windows operating
>systems a
>base level of security based on government guideline and industry best
>practices.
>
>https://github.com/CSD-Public/stonix
>
>The documentation is a bit sketchy, but feel free to check it out.

Thanks for noticing us.
first look impression: big, but well organized.

>Let me know if I can answer any questions.

the readme calls this Alpha stage, I recommend changing accordingly if you 
enter beta
and include directions for testers and expected results.

for this to be useful on Devuan there should be
a simple walkthrough on how to make a testrun on gnu/linux
and perhaps a dryrun flag that won't change configurations



ciao



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


Re: [Dng] Systemd discussions at LinuxQuestions.

2015-05-14 Thread Jude Nelson
Hi James,

On Wed, May 13, 2015 at 11:58 PM, James Powell 
wrote:

>  I agree T. J.
>
> The problem is too much "thinking" about problems, rather than offering a
> clear solution other than scrapping the fore and replacing it entirely
> seems to be the source of the problem.
>
> One argument I stand by adamantly is that while sysvinit was imperfect in
> design, it left room to allow the tree to branch in various ways with the
> applied tools. OpenRC is a prime example of taking sysvinit and expanding
> upon it in a way that allows for diversity just like daemontools, bsd-style
> scripting, and other service supervisors do brilliantly. Sysvinit doesn't
> have to be the workhorse, but it can be the harness providing the standard
> functions of startup and shutdown for the workhorse of your choosing.
>
> However few people are willing to step outside their boxes and look for
> ways to improve systems without resulting to rampant progressivism with new
> software than isn't even finished in it's goals.
>
> In the late 90s Dan Bernstein's daemontools could have ended the
> overreliance on sysvinit, but few embraced it.
>
> Now we see the rush to "do" when something comes along to create a rift.
> No ill will to anyone, but if anyone had have "done" years ago, there might
> be less a need to "do" now.
>

It's not clear to me how much really needed doing in the first place.  The
people who actually needed djb's daemontools went ahead and used them.  The
people who actually needed to contain processes in cgroups did so, and they
did so with vserver and openvz before cgroups existed.  The people who
actually wanted service socket activation used xinted.  The people who
actually needed to start services in parallel either hacked their init
scripts to do so, or wrote Makefiles that started/stopped groups of
services in parallel while enforcing inter-service dependencies as
dependencies between targets.

I think the sudden rush to Fix-All-The-Things we're seeing (the "rampant
progressivism" as you call it) is part of human nature.  I have this pet
theory that people tend to progress through three stages of understanding
when applying themselves to a new field:
(1) they know little or nothing about it, and they know it.
(2) they learn more than they thought there was to know about it, and
(wrongly) believe that they know mostly everything about it.
(3) they reach the field's state-of-the-art and see the boundary between
what is known and unknown, and acquire the humility that comes from
understanding that no matter how much they think they know, there's a lot
more that they don't.

At any given point, there are way more people in stage #1 than stage #2,
and way more people in stage #2 than in stage #3.

The people who are comfortable using the tools I mentioned above tend to be
at stage #3 in the field of building and using UNIX-like operating
systems.  This is because in addition to knowing what tools are available,
they know the trade-offs between them and how to select them to find the
best solution to a particular problem.  They also know when and when not to
create new tools, and they know how to define their scope.  There's no
desire on their end to sacrifice flexibility for convenience--they've dealt
with enough problems to appreciate that having lots of small
interchangeable and composable tools is critical to being able to tackle a
wide variety of them.

Unfortunately, this doesn't do people in stages #1 and #2 any favors.  The
value proposition of systemd is that it automates a common set of stage #3
problem-solving strategies that a stage #1 or #2 user is likely to
encounter, but without requiring the user to have a stage #3 level of
understanding.  I think it's the stage #2 people who appreciate this that
become the loud-mouthed zealots we're all so fond of.  They're the ones who
want to Fix-All-The-Things--they know that there are some hard stage
#3-level problems out there, but they mistakenly believe that they (or
their favorite tool) will know how to fix them.  It's not that they're Bad
People (quite the opposite, they tend to be Concerned Citizens); the
problem is that they know enough to act on the problems they see, but not
enough to know that their solutions aren't always appropriate or desirable.

As a result, enterprising developers who can capitalize on (or even create)
the concerns of the stage #2 people tend to get their software adopted and
stand to gain power, influence, and money from the community.  When stage
#3 people object (as you have), the stage #2 people crowd them out as
"haters", "luddites", "elitists", or "trolls", and the stage #1 people tend
to go along with the stage #2 people since they can't tell stage #2 and
stage #3 people apart, and there are more stage #2 people.  I see all the
noise about systemd as just the latest instance of this phenomenon in my
field.

Just my $0.02.
-Jude


>
> Sent from my Windows Phone
>  --
> From: T.J. Duchene 
> Sent

Re: [Dng] Devuan - Fork or Derivative (or perhaps both)

2015-05-14 Thread Jaromil
dear Daniel,

On 12 May 2015 22:58:24 CEST, Daniel Reurich  wrote:
>Hi
>
>I wonder if Devuan should rebrand it's relationship to Debian as a 
>Derivative rather then a Fork.  It may help to smooth things over a
>bit.
>
>This may also be a good marketing approach as well as reduce the 
>hostility when we send bugreports and patches to debian.

That Debian volunteers are hostile towards bugreports and patches
is not really news and entirely their problem.

Devuan is not antagonizing Debian. Devuan is an exodus made on time
before we'd be enslaved, so we don't carry much resentment and are
happy things are going very well in our camp, for instance we are faster
in fixing things that we consider more important. The clash in fact is over
what we consider more important and it stretched to the point in which we
had to walk back and choose another path, because Debian was disregarding
our concerns and, if we'd have stayed, it would have denied us from taking
care of them.

therefore Devuan is a fork

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


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Jude Nelson
Hi James,
On Thu, May 14, 2015 at 12:04 AM, James Powell 
wrote:

>  Thanks Jude.
>
> The Slackware package is delayed, but only due to the lack of a Slackware
> style script. I might try to ask one of the Slackware team for assistance
> when I resume work. However, the package is fairly much completed in terms
> of installation points and directory setup.
>

Hey, that's pretty cool!  First the AUR packages (from Jack Frost aka
openfbt), now Slackware.

I'm not a Slackware or Arch user, but please let me know if there's
anything I can do to make packaging easier?  I don't want to make things
needlessly difficult :)

-Jude


> Sent from my Windows Phone
>  --
> From: Jude Nelson 
> Sent: 5/13/2015 8:24 PM
> To: dng@lists.dyne.org
> Subject: [Dng] [dng] vdev status update (2015-05-03)
>
>  Hey everyone,
>
>  I have the latest news for vdev:
>
> * vdev now creates symlinks for:
> -- /dev/v4l/by-path
> -- /dev/disk/by-partuuid
> -- /dev/disk/by-partlabel
>
>  Thank you Scooby for helping me confirm this!
>
>  * vdev now sets the proper ownership and permissions for:
>  -- /dev/mISDNtimer
> -- /dev/mwave
> -- /dev/parport[0-9]
> -- /dev/printer
> -- /dev/ppdev
> -- /dev/lp[0-9]
> -- /dev/irlpt[0-9]
> -- /dev/sch[0-9]
> -- /dev/pktcdvd[0-9]
> -- /dev/qft[0-9]
> -- /dev/zqft[0-9]
> -- /dev/nqft[0-9]
> -- /dev/nzqft[0-9]
> -- /dev/rawqft[0-9]
> -- /dev/nraqft[0-9]
> -- /dev/rawctl
> -- /dev/aoe
> -- /dev/lirc[0-9]
> -- /dev/legousbtower
> -- /dev/sonypi
> -- /dev/mmtimer
> -- /dev/sgi_*
> -- /dev/z90crypt
>
>  * Didier Kryn has gotten vdevd and vdevfs to statically link and compile
> with musl libc.  I'm looking forward to merging his contributions :)
>
>  * the build system has been refactored to use Makefiles more
> appropriately:
> -- every generated file gets written to a separate build/ directory
> -- every generated file is created by a non-phony target (i.e. nothing
> happens by side-effect)
> -- global buildconf.mk for setting variables
> Thanks to Didier again for the suggestion!
>
>  * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> blkid, etc.  Moreover, vdev's helpers conditionally use these programs if
> they are present.  This means that vdev doesn't strictly depend on them
> anymore, which is good if you're not using mapped devices or logical
> volumes.  Thanks to Anto for the suggestion!
>
> * the initramfs hook pulls in the correct GNU libc files now, so chown(1)
> will work correctly in the initramfs.  Thanks to Scooby, Isaac Dunham, Tom
> H for their help!
>
>
> [For Next Time]
>
>  * The next immediate objective is to package vdevd for Devuan, to make
> it easier to test (in particular, easier to get a working initramfs).  I'm
> currently dissecting udev's packaging and reading through Isaac's mdev
> scripts to see what to expect and what we can recycle.  I've never packaged
> something this complex before.  Thanks to Scooby, Anto, Tom H, and others
> for all their help on getting me this far!
>
>  * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends).
> I don't run a RAID myself, so I'll need to go set one up in QEMU.  If
> someone wants to test vdev with a RAID, let me know, and I'll try to write
> a helper script to play around with sooner rather than later.
>
>  * In some distros and configurations, a separate device manager (like
> mdev) can populate just enough of /dev to mount root, but not try to set up
> any symlinks.  Vdevd must have a way for the admin to tell it to run helper
> scripts for the device even if its device node was already created
> (indicating that it has been set up), so the symlinks and permissions still
> get set appropriately.  Thanks to Scooby for reporting this!
>
>  Thanks,
> -Jude
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Jack L. Frost
On Wed, May 13, 2015 at 06:33:34PM -0500, T.J. Duchene wrote:
> Has something happened with standard udev that you are looking to switch?  
> I've not heard anything lately, but that does not make immediate sense to me. 
>  

I'm not the one you're asking, but I'll provide one reason to switch:
udev is a part of the systemd project, and in the near future it will probably
stop being packaged outside of systemd for it is a lot of work to do so.
Switching now is a good idea as opposed to switching later down the line when
it's suddenly packaged with systemd and you have to install all of it to get
udev.


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


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Jack L. Frost
On Thu, May 14, 2015 at 03:33:06AM -0400, Jude Nelson wrote:
> I'm not a Slackware or Arch user, but please let me know if there's
> anything I can do to make packaging easier?  I don't want to make things
> needlessly difficult :)

I've dropped an issue on github about the new Makefiles, yeah :)


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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Arnt Gulbrandsen
Doing work now because it "is sure to be needed at some point" is one 
of the major problems fixed by XP and agile development. Google for 
YAGNI. So why is it a good idea in this case?


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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Hendrik Boom
On Thu, May 14, 2015 at 12:20:00PM +, Arnt Gulbrandsen wrote:
> Doing work now because it "is sure to be needed at some point" is
> one of the major problems fixed by XP and agile development. Google
> for YAGNI. So why is it a good idea in this case?

Isn't our situation  more a case of removing thing you're not going to need?

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Jack L. Frost
On Thu, May 14, 2015 at 12:20:00PM +, Arnt Gulbrandsen wrote:
> Doing work now because it "is sure to be needed at some point" is
> one of the major problems fixed by XP and agile development. Google
> for YAGNI. So why is it a good idea in this case?

I have not heard good arguments against planning for the future in the first
place.


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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Anto



On 14/05/15 13:49, Jack L. Frost wrote:

On Wed, May 13, 2015 at 06:33:34PM -0500, T.J. Duchene wrote:

Has something happened with standard udev that you are looking to switch?  I've 
not heard anything lately, but that does not make immediate sense to me.

I'm not the one you're asking, but I'll provide one reason to switch:
udev is a part of the systemd project, and in the near future it will probably
stop being packaged outside of systemd for it is a lot of work to do so.
Switching now is a good idea as opposed to switching later down the line when
it's suddenly packaged with systemd and you have to install all of it to get
udev.


I think that has already happened for quite some time. The latest udev 
package outside systemd source in Debian is 175-7.2 according to 
https://tracker.debian.org/pkg/udev. In Debian jessie it is provided by 
systemd package as shown on https://tracker.debian.org/pkg/systemd. I am 
still on Debian wheezy with *systemd* pinned to Pin-Priority: -1. When I 
tried to switched to jessie repository and do dist-upgrade, udev package 
is not being pulled.


According to Jaret on 
https://lists.dyne.org/lurker/message/20150506.032423.0a2c83ef.en.html, 
udev source has been merged into systemd source since version 183.


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


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread shraptor shraptor
 I would be interested in a static Vdev.

Didier could you please give some info
how this was done especially any gotcha's
you found?

On Thursday, May 14, 2015, Jack L. Frost  wrote:

> On Thu, May 14, 2015 at 03:33:06AM -0400, Jude Nelson wrote:
> > I'm not a Slackware or Arch user, but please let me know if there's
> > anything I can do to make packaging easier?  I don't want to make things
> > needlessly difficult :)
>
> I've dropped an issue on github about the new Makefiles, yeah :)
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Steve Litt
On Thu, 14 May 2015 15:40:59 +0200
shraptor shraptor  wrote:

>  I would be interested in a static Vdev.

So would I. I could just slide that right onto my Valentine VM, without
compilation and dependencies. Once I get familiar with vdev itself, I
could install one with loadable modules.


SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Steve Litt
On Wed, 13 May 2015 23:24:42 -0400
Jude Nelson  wrote:

> Hey everyone,
> 
> I have the latest news for vdev:
> 
> * vdev now creates symlinks for:
> -- /dev/v4l/by-path
> -- /dev/disk/by-partuuid
> -- /dev/disk/by-partlabel

Thank you Jude. It's astounding what you've been able to accomplish.

 
> * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> blkid, etc. 

I can think of few things more brain taxing than writing a program to
tweak a RAM filesystem and accompanying init script that will be used
on the *next* boot. Troubleshooting and experimentation must be a slow
process, with boots intervening. Even on a VM on a fast host.

> 
> 
> [For Next Time]
> 
> * The next immediate objective is to package vdevd for Devuan, to
> make it easier to test (in particular, easier to get a working
> initramfs).  

Could you please make sure that there's a way for us Qemu users to use
it? I don't know whether I'm the only one, but Vagrant errors out on my
Debian Wheezy machine. So I'm still using the Valentine edition.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread T.J. Duchene
> 
> I think that has already happened for quite some time. The latest udev
> package outside systemd source in Debian is 175-7.2 according to
> https://tracker.debian.org/pkg/udev. In Debian jessie it is provided by
> systemd package as shown on https://tracker.debian.org/pkg/systemd. I am
> still on Debian wheezy with *systemd* pinned to Pin-Priority: -1. When I
> tried to switched to jessie repository and do dist-upgrade, udev package is
> not being pulled.
> 
[T.J. ]  I can understand your reticence, certainly.  All I'm advocating is a 
"common sense" engineering approach. I think it is advantageous that udev be 
included as an option for those who prefer to make certain that no unforeseen 
incompatibilities creep in. Use udev, eudev, vdev or none of the above, the end 
user should be the one to make that decision, although Devuan could certainly 
chose a preference for default.

There is no technical reason to exclude udev.Whatever discussions are in 
progress, the fact it can be built from the same source package as systemd is 
entirely immaterial from an engineering standpoint.  Besides, if Devuan forces 
users to use only their preferences, Devuan risks future fragmentation.  Debian 
already made that mistake.

Anyway, that's just the way I see it. 



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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Anto



On 14/05/15 17:53, T.J. Duchene wrote:

I think that has already happened for quite some time. The latest udev
package outside systemd source in Debian is 175-7.2 according to
https://tracker.debian.org/pkg/udev. In Debian jessie it is provided by
systemd package as shown on https://tracker.debian.org/pkg/systemd. I am
still on Debian wheezy with *systemd* pinned to Pin-Priority: -1. When I
tried to switched to jessie repository and do dist-upgrade, udev package is
not being pulled.


[T.J. ]  I can understand your reticence, certainly.  All I'm advocating is a 
"common sense" engineering approach. I think it is advantageous that udev be 
included as an option for those who prefer to make certain that no unforeseen 
incompatibilities creep in. Use udev, eudev, vdev or none of the above, the end user 
should be the one to make that decision, although Devuan could certainly chose a 
preference for default.

There is no technical reason to exclude udev.Whatever discussions are in 
progress, the fact it can be built from the same source package as systemd is 
entirely immaterial from an engineering standpoint.  Besides, if Devuan forces 
users to use only their preferences, Devuan risks future fragmentation.  Debian 
already made that mistake.

Anyway, that's just the way I see it.



I think the fact that I pointed out clearly shows that there is very 
good technical reason to exclude udev, unless you are willing to be the 
maintainer of udev outside systemd source tree in Devuan.


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


Re: [Dng] Systemd discussions at LinuxQuestions.

2015-05-14 Thread miro . rovis
On Thu, May 14, 2015 at 03:25:46AM -0400, Jude Nelson wrote:

I'm really sorry for having sent the same message four times. However,
it's my (urgh, "kind") provider who kept me from both receiving the
messages of that thread and kept the old cached:

( with the same topic as the subject of this email )
https://lists.dyne.org/lurker/message/20150510.211708.6d1d46ab.en.html

for almost five hours, so I couldn't know it was received.

unless there were issues with lurker (were there any issues with it?).

The whole story is on:

https://forums.gentoo.org/viewtopic-t-999436.html#7746644

and

https://forums.gentoo.org/viewtopic-t-999436.html#7747902

Sorry for the digression.

And, I'll try and post about dbus to Devuan ML, as I say I would in my topic:

Grsecurity/Pax installation on Debian GNU/Linux
http://forums.debian.net/viewtopic.php?f=16&t=108616&start=60#p577538
where find strings `Devuan' and esp. `no-dbus Devuan'.

> Hi James,
> 
> On Wed, May 13, 2015 at 11:58 PM, James Powell 
> wrote:
> 
> >  I agree T. J.
> >
> > The problem is too much "thinking" about problems, rather than offering a
> > clear solution other than scrapping the fore and replacing it entirely
> > seems to be the source of the problem.
> >
> > One argument I stand by adamantly is that while sysvinit was imperfect in
> > design, it left room to allow the tree to branch in various ways with the
> > applied tools. OpenRC is a prime example of taking sysvinit and expanding
> > upon it in a way that allows for diversity just like daemontools, bsd-style
> > scripting, and other service supervisors do brilliantly. Sysvinit doesn't
> > have to be the workhorse, but it can be the harness providing the standard
> > functions of startup and shutdown for the workhorse of your choosing.
> >
> > However few people are willing to step outside their boxes and look for
> > ways to improve systems without resulting to rampant progressivism with new
> > software than isn't even finished in it's goals.
> >
> > In the late 90s Dan Bernstein's daemontools could have ended the
> > overreliance on sysvinit, but few embraced it.
> >
> > Now we see the rush to "do" when something comes along to create a rift.
> > No ill will to anyone, but if anyone had have "done" years ago, there might
> > be less a need to "do" now.
> >
> 
> It's not clear to me how much really needed doing in the first place.  The
> people who actually needed djb's daemontools went ahead and used them.  The
> people who actually needed to contain processes in cgroups did so, and they
> did so with vserver and openvz before cgroups existed.  The people who
> actually wanted service socket activation used xinted.  The people who
> actually needed to start services in parallel either hacked their init
> scripts to do so, or wrote Makefiles that started/stopped groups of
> services in parallel while enforcing inter-service dependencies as
> dependencies between targets.
> 
> I think the sudden rush to Fix-All-The-Things we're seeing (the "rampant
> progressivism" as you call it) is part of human nature.  I have this pet
> theory that people tend to progress through three stages of understanding
> when applying themselves to a new field:
> (1) they know little or nothing about it, and they know it.
> (2) they learn more than they thought there was to know about it, and
> (wrongly) believe that they know mostly everything about it.
> (3) they reach the field's state-of-the-art and see the boundary between
> what is known and unknown, and acquire the humility that comes from
> understanding that no matter how much they think they know, there's a lot
> more that they don't.
> 
> At any given point, there are way more people in stage #1 than stage #2,
> and way more people in stage #2 than in stage #3.
> 
> The people who are comfortable using the tools I mentioned above tend to be
> at stage #3 in the field of building and using UNIX-like operating
> systems.  This is because in addition to knowing what tools are available,
> they know the trade-offs between them and how to select them to find the
> best solution to a particular problem.  They also know when and when not to
> create new tools, and they know how to define their scope.  There's no
> desire on their end to sacrifice flexibility for convenience--they've dealt
> with enough problems to appreciate that having lots of small
> interchangeable and composable tools is critical to being able to tackle a
> wide variety of them.
> 
> Unfortunately, this doesn't do people in stages #1 and #2 any favors.  The
> value proposition of systemd is that it automates a common set of stage #3
> problem-solving strategies that a stage #1 or #2 user is likely to
> encounter, but without requiring the user to have a stage #3 level of
> understanding.  I think it's the stage #2 people who appreciate this that
> become the loud-mouthed zealots we're all so fond of.  They're the ones who
> want to Fix-All-The-Things--they know that there are some hard sta

Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Didier Kryn


Le 14/05/2015 15:40, shraptor shraptor a écrit :

 I would be interested in a static Vdev.

Didier could you please give some info
how this was done especially any gotcha's
you found?


Hi Shraptor.

I have been working for almost one year, partial time, on building 
a sysrooted gcc-4.7 bundled with musl-1.1.5. This has been pretty 
difficult for me, since I am not an expert in Gcc and I could not find 
it ready-made because I wanted this gcc to understand all languages, 
including Ada. With Ada, there is a bootstrapping problem because it can 
be compiled only with the current version or the previous.


I started from a chroot containing Sabotage-Linux, which has no 
Ada, in which I introduced Gnat from Debian Wheezy and I don't remember 
exactly how I finally succeeded, last november :-) the fact is that I 
have now a working sysrooted toolchain which can recompile itself and 
can compile a lot of applications. Sabotage provides the necessary 
patches for gcc to work with Musl - Big thanks to them - and I patched 
Gnat myself. The whole process looks like a horrible bricolage, and it 
was just that.


With this (kind of cross) toolchain, installed on my Debian Wheezy 
laptop, I have succeeded to compile the whole package from Jude, 
including the filesystem, which is not even an alpha release AFAIU, but 
has some dependencies and was a good exercise. The main work was to 
modify the Makefiles so that they can produce static archive libraries 
and replacing one glibc non-standard macro with the standard one.


I am now working on producing a bootable USB flash disk with two 
partitions, one containing the kernel and the Syslinux bootloader files 
and one with the root filesystem containing Busybox-1.23.1, Vdevd and 
its helpers, and even  Bash, all statically linked against Musl. I tried 
to boot it 15mn ago but my kernel is still missing some drivers to be 
able to mount the usb key. I chose this configuration, rather than an 
initramfs, to be able to make persistent changes to my root filesystem, 
but it means that all the drivers needed to mount the root partition 
must be compiled in the kernel instead of loadable modules.


I am very excited at seeing vdev in action and I don't think I will 
do anything else before I see if it works. Then I promised to Jude to 
send him the necessary patches. I think that, with the patched version 
of vdev, you could compile it statically with any ready-made gcc-musl 
toolchain (eg Sabotage). Could you wait a few days more?


Didier

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread T.J. Duchene

> I think the fact that I pointed out clearly shows that there is very good
> technical reason to exclude udev, unless you are willing to be the maintainer
> of udev outside systemd source tree in Devuan.

[T.J. ] Please understand that I very much respect your position, and I agree 
with you that a "put up or shut up" attitude can be warranted in many 
instances.   However, I do not believe that this is one of them.  The shortest 
and most reasonable route to release a stable 1.0 of Devuan is to use udev for 
the present.  THAT in and of itself trumps your concerns in my opinion.  I will 
admit that I find Jude's proposal intriguing - but it is hardly ready for use.  
Eudev might make a good replacement, but udev is still the best candidate in 
terms of people using it if you follow the principle that "eyes make bugs 
shallow".

What I am going to say next is no reflection on you, nor anyone else here.  But 
since the subject came up, I will be straightforward with you.  I know that 
some might take offense to what I am going to say, and that's fine.  If you 
feel that I should not make future comment, then by all means, please ignore 
me, and I won't speak further with you on the subject.

I could maintain udev, if I were actually part of Devuan.  While I have 
recently returned to the list, I am waiting to see what Devuan is going to do 
with 1.0 before I decide to commit any effort to the project.  If one of the 
VUAs asked me to assist with a specific task, I would consider it - but 
otherwise, I will not.   Past experience with the Devuan community has left me 
in a position of uncertainty about becoming actively involved at all.  From my 
point of view, past conversations here have been as "toxic" as Debian and the 
rest of Linux in general.  

I find that tiresome, and until I see something to inspire me, I am unmoved. 


Best regards
T.J.






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


Re: [Dng] Systemd discussions at LinuxQuestions.

2015-05-14 Thread T.J. Duchene
You both made good points. I've been around a while, so I'll just speak my
mind.  If that bothers anyone, please "plug your ears."


I've used Unix before Linux existed, and after.  I've seen ideas come and
go.  Systemd is absolutely nothing new, nor is the community reaction to it
even surprising.  Linux thrives on confrontation because everyone (their
granny, their aunt, and their uncle) can have a stake in it and that is just
"honkey-dory" as the euphemism goes. The problem with Linux is that younger
programmers tend to dominate the more vocal discussions.  They are usually
lacking in practical experience, and coming from long exposure to non-Unix
cultures.  Because Linux lives on confrontation more than cooperation, their
views come to be seen as the view of the whole.

Mr. Poettering is a classic example of the "new Linux."  I'm not just
talking about systemd, but that virtually the entire Linux community has
bought into this idea that Linux is more important than open standards such
as POSIX, and code portability should be abandoned - effectively developing
Linux as an isolated community. This is, quite bluntly: egregiously *stupid*
even in the most indirect sense.   I won't waste time with a laundry list of
"whys" unless someone asks for it.  

Thankfully, at present, their *dementia* is still somewhat contained.   They
do not see that they are making the same mistakes that Microsoft made 15-20
years ago.  Microsoft was an original signatory to the POSIX standard, but
then abandoned it in 2000 with the release of Windows 2000.  They kept just
enough of POSIX to meet government requirements as I recall.  They later
dropped even that as they become the dominant player.  Linux is doing
exactly the same, much to my disappointment.  I call it for what it is:
arrogance - arrogance and stupidity.  Microsoft did not gain from abandoning
POSIX or open standards over the long term.  It came back to bite them in
the ass, and now they are actually reversing that under Satya Nadella,
albeit very slowly.

 

Microsoft's self-imposed isolation was killing it, and now we see Linux
making the same error.  I've pretty much adopted a perspective of "stupid is
as stupid does" in regard to Linux.  It is a much lower regard than I used
to have because Linux has let success "go to their heads".  POSIX deserves
much of the credit.  Linux owes POSIX a lot, and after it manages to excise
it completely, I see Linux losing stature to someone else who is more
willing to work cooperatively.

 

 

 

 



 

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Jude Nelson
Following up to what T.J. said...

On Thu, May 14, 2015 at 1:15 PM, T.J. Duchene  wrote:

>
> > I think the fact that I pointed out clearly shows that there is very good
> > technical reason to exclude udev, unless you are willing to be the
> maintainer
> > of udev outside systemd source tree in Devuan.
>
> [T.J. ] Please understand that I very much respect your position, and I
> agree with you that a "put up or shut up" attitude can be warranted in many
> instances.   However, I do not believe that this is one of them.  The
> shortest and most reasonable route to release a stable 1.0 of Devuan is to
> use udev for the present.  THAT in and of itself trumps your concerns in my
> opinion.  I will admit that I find Jude's proposal intriguing - but it is
> hardly ready for use.  Eudev might make a good replacement, but udev is
> still the best candidate in terms of people using it if you follow the
> principle that "eyes make bugs shallow".
>

I thought it was already settled and decided by the VUA that Devuan Jessie
will use udev.  I agree with this stance, for the same reason as T.J.
points out--udev is production-ready, whereas vdev is not.  It's the
pragmatic thing to do--I only have a handful of hours per week to work on
vdev, so it makes no sense to hold up the release waiting for it.

However, I think the plan is to offer vdev as a udev alternative in at
least ascii, so users who want to try it out will be able to do so with
minimal effort.

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


Re: [Dng] Systemd discussions at LinuxQuestions.

2015-05-14 Thread Nate Bargmann
Well said, T.J.  I couldn't find anything to disagree with in your
missive.  I will also add that now a technical disagreement seems to
have morphed into somehow opposing the pet cause of various social
justice warriors that now seem to be everywhere.  One such recent
example is from Debian Developer Russell Coker (I'll not provide a link,
it can be found easily enough) where "anti-systemd" people are grouped
into a very unflattering minority of persons.  This belies any assertion
that systemd is anything but political.

I am certainly leaning toward minimalism these days and I appreciate
efforts of DIY by Steve.  I look for Devuan to be a distribution where I
can mix and match the pieces as I see fit and for what works for me.  If
that leaves some SJW laying awake at night, so much the better.

- 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] A novice attempt to speed up Devuan development

2015-05-14 Thread T.J. Duchene
 

I thought it was already settled and decided by the VUA that Devuan Jessie
will use udev.  I agree with this stance, for the same reason as T.J. points
out--udev is production-ready, whereas vdev is not.  It's the pragmatic
thing to do--I only have a handful of hours per week to work on vdev, so it
makes no sense to hold up the release waiting for it.

 

However, I think the plan is to offer vdev as a udev alternative in at least
ascii, so users who want to try it out will be able to do so with minimal
effort.

 

[T.J. ] Hello, Jude!  

I believe that this is just a friendly discussion regarding the merits of
udev, and is of no concern to anything further.  I have no knowledge of the
release plans, nor would I jump into this conversation if I actually did.
Plans tend to change and the VUAs do not seem to discuss development matters
here.

 

 

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


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Jude Nelson
Hi Steve,

On Thu, May 14, 2015 at 11:03 AM, Steve Litt 
wrote:

> On Wed, 13 May 2015 23:24:42 -0400
> Jude Nelson  wrote:
>
> > Hey everyone,
> >
> > I have the latest news for vdev:
> >
> > * vdev now creates symlinks for:
> > -- /dev/v4l/by-path
> > -- /dev/disk/by-partuuid
> > -- /dev/disk/by-partlabel
>
> Thank you Jude. It's astounding what you've been able to accomplish.
>

Thanks!  Fortunately, it's not as bad as it looks--it's mostly a matter of
reading the udev rules files and writing a script that does the same thing
:)


>
>
> > * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> > blkid, etc.
>
> I can think of few things more brain taxing than writing a program to
> tweak a RAM filesystem and accompanying init script that will be used
> on the *next* boot. Troubleshooting and experimentation must be a slow
> process, with boots intervening. Even on a VM on a fast host.
>

Yeah, it can get pretty tedious.  Fortunately, I'm using a minimal QEMU
image, so reboots happen pretty fast (i.e. the working set fits entirely in
my disk cache).

I have developed a new-found appreciation for the people who designed
Debian's initramfs system.  Despite the tediousness of building cpio
images, Debian's initramfs-tools package is surprisingly flexible and
well-documented.  There are a couple little things it could make the
process less painful, though; I'm in the process of getting together some
patches to send to Debian, if they're interested.


> >
> >
> > [For Next Time]
> >
> > * The next immediate objective is to package vdevd for Devuan, to
> > make it easier to test (in particular, easier to get a working
> > initramfs).
>
> Could you please make sure that there's a way for us Qemu users to use
> it? I don't know whether I'm the only one, but Vagrant errors out on my
> Debian Wheezy machine. So I'm still using the Valentine edition.
>

Absolutely!  I intend to make the first iteration of packages available as
direct downloads (will post hashes to the ML), and will continue to do so
until I can figure out how to hook the vdev repository into Devuan's CI
system.

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Anto



On 14/05/15 19:15, T.J. Duchene wrote:

I think the fact that I pointed out clearly shows that there is very good
technical reason to exclude udev, unless you are willing to be the maintainer
of udev outside systemd source tree in Devuan.

[T.J. ] Please understand that I very much respect your position, and I agree with you that a 
"put up or shut up" attitude can be warranted in many instances.   However, I do not 
believe that this is one of them.  The shortest and most reasonable route to release a stable 1.0 
of Devuan is to use udev for the present.  THAT in and of itself trumps your concerns in my 
opinion.  I will admit that I find Jude's proposal intriguing - but it is hardly ready for use.  
Eudev might make a good replacement, but udev is still the best candidate in terms of people using 
it if you follow the principle that "eyes make bugs shallow".

What I am going to say next is no reflection on you, nor anyone else here.  But 
since the subject came up, I will be straightforward with you.  I know that 
some might take offense to what I am going to say, and that's fine.  If you 
feel that I should not make future comment, then by all means, please ignore 
me, and I won't speak further with you on the subject.

I could maintain udev, if I were actually part of Devuan.  While I have recently returned 
to the list, I am waiting to see what Devuan is going to do with 1.0 before I decide to 
commit any effort to the project.  If one of the VUAs asked me to assist with a specific 
task, I would consider it - but otherwise, I will not.   Past experience with the Devuan 
community has left me in a position of uncertainty about becoming actively involved at 
all.  From my point of view, past conversations here have been as "toxic" as 
Debian and the rest of Linux in general.

I find that tiresome, and until I see something to inspire me, I am unmoved.


Best regards
T.J.



Hello T.J.,

I didn't mean to express anything related to "put up or shut up". This 
is a public forum so anybody can express their opinions. For me, I don't 
really care whether everybody else agree or not on my opinions so I 
don't really take it seriously.


This is similar to my comment to Noel the other day, in regards to the 
effort and freedom of choice. So my opinion remains the same.


What I thought important for Devuan now is to be ready and to release 
the first version. So I am sorry that I always post strong opinions on 
the ideas that I thought might distract the development of Devuan, 
especially on the ideas in providing choices for the users without 
considering the efforts in implementing and maintaining them in Devuan. 
It would be totally different story if the ones who post the idea would 
be willing to volunteer to do that in Devuan. I don't think anybody in 
the core Devuan development team would ask everybody individually for 
that. I believe everybody who share the same interest can volunteer and 
join Devuan development team. Unfortunately, I am not a programmer 
otherwise I would volunteer myself to maintain packages for Devuan.


In regards to udev, I cannot find any Debian style udev package source 
that is being maintained outside systemd source tree so far, a part from 
the one in Debian wheezy which is quite old. That tells me that it is 
not worth the effort to maintain it outside systemd source tree. But if 
you knew anything about that, please do share that with us. Perhaps 
somebody who has the skill could take that and add it into Devuan 
package source.


Cheers,

Anto

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread miro . rovis
On Thu, May 14, 2015 at 10:53:20AM -0500, T.J. Duchene wrote:
> > 
> > I think that has already happened for quite some time. The latest udev
> > package outside systemd source in Debian is 175-7.2 according to
> > https://tracker.debian.org/pkg/udev. In Debian jessie it is provided by
> > systemd package as shown on https://tracker.debian.org/pkg/systemd. I am
> > still on Debian wheezy with *systemd* pinned to Pin-Priority: -1. When I
> > tried to switched to jessie repository and do dist-upgrade, udev package is
> > not being pulled.
> > 
> [T.J. ]  I can understand your reticence, certainly.  All I'm advocating is a
> "common sense" engineering approach. I think it is advantageous that udev be
> included as an option for those who prefer to make certain that no unforeseen
> incompatibilities creep in. Use udev, eudev, vdev or none of the above, the

Right! It is assuring to me to see that approach. I can't tell how little if
any problems I have in Gentoo with eudev, which is there but you never notice
it, and I'll really opt for eudev, if the mistakes that Debian made... see
below, pls...

> end user should be the one to make that decision, although Devuan could
> certainly chose a preference for default.
> 
> There is no technical reason to exclude udev.Whatever discussions are in
> progress, the fact it can be built from the same source package as systemd is
> entirely immaterial from an engineering standpoint.  Besides, if Devuan
> forces users to use only their preferences, Devuan risks future
> fragmentation.  Debian already made that mistake.

If that mistake is not made in Devuan.

Are there others of you devs (I'm just somewhat advanced user, but I watch
anxiously to see Devuan really taking off and learning to fly, and I already
recommended you in quite a few places in my not little visited forum topics on
Gentoo Forums and elsewhere.)...

Are there others of you devs and users-to-be (like, hopefully, me), who
understand the distinction btwn poetterware and true FOSS programs (to make the
distincion simplified)?

I mean, if I wouldn't be able to rid my Devuan of any poetterware (and lots of
systemd known and lesser known friends and associate programs go into that
category), then I would have to search for other ways to live without it.

The best way to see what peotterware is, apart from the distant but very
strong and very needed associate dbus, is, say, go to:

https://eurynome.mirbsd.org/debs/debidx.htm

and see which one one of the FOSS wizards like some of you founders and
developers of Devuan are too, Thorsten mirabilos Glaser, chose to remove from
Debian.

And which I was able to do in Debian:

How to Remove Systemd and Related Packages from Your Debian 
http://forums.debian.net/viewtopic.php?f=16&t=118197

That really need to be achievable in Devuan too!

Thanks for all of your efforts, I really hope Devuan takes off and shines, the
new sun, as my friend from Debian Forums, edbarx, usually says.

# A private digression follows. Readers, freely skip this, but anyhow remember
# the line above on what must be achievable in Devuan too!

Greetings also to golinux. golinux, I received your message many weeks ago now,
but I don't know if you received my reply back then, If I don't get to know
that and see you still around, I'll create a page at:

http://www.CroatiaFidelis.hr/foss/cenz

and post my reply to it. No other way. What? sending many times again? Sorry!

Sorry for this digression.
-- 
Miroslav Rovis
Zagreb, Croatia
http://www.CroatiaFidelis.hr


pgphVob00eJjj.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Anto



On 14/05/15 19:42, Jude Nelson wrote:


I thought it was already settled and decided by the VUA that Devuan 
Jessie will use udev.  I agree with this stance, for the same reason 
as T.J. points out--udev is production-ready, whereas vdev is not.  
It's the pragmatic thing to do--I only have a handful of hours per 
week to work on vdev, so it makes no sense to hold up the release 
waiting for it.




Hello Jude,

I didn't know that it was already settled and decided that Devuan jessie 
will use udev. I have not seen any udev package in Devuan repositories 
nor in Devuan gitlab. Do you know which repositories in Devuan hold the 
source of udev outside systemd source tree?


Cheers,

Anto

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Svante Signell
On Thu, 2015-05-14 at 12:15 -0500, T.J. Duchene wrote:
> > I think the fact that I pointed out clearly shows that there is very good
> > technical reason to exclude udev, unless you are willing to be the 
> > maintainer
> > of udev outside systemd source tree in Devuan.
> 

> The shortest and most reasonable route to release a stable 1.0 of
> Devuan is to use udev for the present.

See below.

>  Eudev might make a good
> replacement, but udev is still the best candidate in terms of people
> using it if you follow the principle that "eyes make bugs shallow".

People are working _now_ on eudev as a replacement for udev until vdev
is finished. It might even be a good replacement for udev already for
the devuan jessie release. What do you do, except chat?

>  From my point of view, past
> conversations here have been as "toxic" as Debian and the rest of Linux
> in general.  

I think you are alone on this, sorry.

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread T.J. Duchene
> Hello T.J.,
> 
> I didn't mean to express anything related to "put up or shut up".  

 
Actually, I am someone who would pat you on the back if you did.  Talk is 
cheap, and quite frankly, I when dealing with Linux fans I often hear a lot of 
talk and see very little.  I feel you handled it with respect, and so no 
offense was ever suggested nor taken by myself.  Just because we happen to 
disagree does not mean you gave offense.

I have a decent regard for Jude's project.  I may not always agree with people, 
but Jude putting his ideas to the test, and I say good for him.



>Unfortunately, I am not a programmer
> otherwise I would volunteer myself to maintain packages for Devuan.

Devuan needs more than programmers.  There are documentation writers, graphic 
designers, public relations, even just fans.  I know coders get a lot of the 
spotlight, but without others Devuan isn't going to go anywhere either. 


> In regards to udev, I cannot find any Debian style udev package source that is
> being maintained outside systemd source tree so far, a part from the one in
> Debian wheezy which is quite old. 

Why would you?  Wheezy is the last release without systemd, and since Jessie 
uses systemd by default, they have no reason to maintain a separate source 
package.  You think that they would for the sake of users who do not want 
systemd, right?  The moment I heard that Ian Jackson's general resolution  had 
failed, I suspected that for all "real world" or practical purposes it had the 
effect of Debian saying that you can use systemd-shim in Jesse, but that it 
will be nothing but a pacifier to silence future opposition until systemd 
becomes mandatory in Debian.  No one actually said that aloud, but I consider 
it the end result.
  
 >That tells me that it is not worth the effort
> to maintain it outside systemd source tree. But if you knew anything about
> that, please do share that with us. 

I don't claim to know anything that you do not.  That is basically what Eudev 
is.  A version of udev forked by Gentoo after udev became maintained inside of 
systemd's source code. 


> Perhaps somebody who has the skill could
> take that and add it into Devuan package source.

I would presume that Devuan has that well in hand.  They would have to address 
it before release.

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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread T.J. Duchene
> 
> People are working _now_ on eudev as a replacement for udev until vdev is
> finished. It might even be a good replacement for udev already for the
> devuan jessie release. 

[T.J. ]   That's very interesting and information I did not know.  You have to 
admit that actual development details regarding Devuan are not posted to the 
mailing list often.  If it is actually you working on it, then my hat is off to 
you.  I would not personally consider it a good choice for a Devuan 1.0 
release, but my opinion in that regard is entirely moot, as I am not a member 
of the Devuan development team.


>What do you do, except chat?
[T.J. ] Some would interpret that as an attempt to annoy.  If you are somehow 
offended, I apologize for that - but I am going to express a technical opinion 
from time to time, even if it happens to be unpopular, such as saying at 
present that udev is better choice.  I noted that Jude happens to agree with 
me.  If you feel that this is not the proper forum for such, please enlighten 
me, and I will take my comments elsewhere. 

> >  From my point of view, past
> > conversations here have been as "toxic" as Debian and the rest of
> > Linux in general.
> 
> I think you are alone on this, sorry.
[T.J. ] Fair enough.  =)  I happen to disagree, but that is really of no 
consequence.

 


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


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Anto



On 14/05/15 22:16, T.J. Duchene wrote:
Devuan needs more than programmers. There are documentation writers, 
graphic designers, public relations, even just fans. I know coders get 
a lot of the spotlight, but without others Devuan isn't going to go 
anywhere either. 


It would be great if I could contribute as document writer. But I am 
even still having difficulties to express myself in English as it is my 
4th language. German is my 5th language and I am worse at it than 
English. I don't have artistic mind so I should forget to contribute as 
graphic designer. So the only thing I can offer to Devuan is testing it 
report any issues that I find, a part from complaining and expressing my 
opinions.


One of the main reasons I started this thread is to get suggestions and 
guidelines in rebuilding Debian packages for Devuan so that I can 
contribute more than that.


Cheers,

Anto

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


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread shraptor shraptor
On Thursday, May 14, 2015, Didier Kryn  wrote:

>
> Le 14/05/2015 15:40, shraptor shraptor a écrit :
>
>>  I would be interested in a static Vdev.
>>
>> Didier could you please give some info
>> how this was done especially any gotcha's
>> you found?
>>
>
> Hi Shraptor.
>
> I have been working for almost one year, partial time, on building a
> sysrooted gcc-4.7 bundled with musl-1.1.5. This has been pretty difficult
> for me, since I am not an expert in Gcc and I could not find it ready-made
> because I wanted this gcc to understand all languages, including Ada. With
> Ada, there is a bootstrapping problem because it can be compiled only with
> the current version or the previous.
>
> I started from a chroot containing Sabotage-Linux, which has no Ada,
> in which I introduced Gnat from Debian Wheezy and I don't remember exactly
> how I finally succeeded, last november :-) the fact is that I have now a
> working sysrooted toolchain which can recompile itself and can compile a
> lot of applications. Sabotage provides the necessary patches for gcc to
> work with Musl - Big thanks to them - and I patched Gnat myself. The whole
> process looks like a horrible bricolage, and it was just that.
>
> With this (kind of cross) toolchain, installed on my Debian Wheezy
> laptop, I have succeeded to compile the whole package from Jude, including
> the filesystem, which is not even an alpha release AFAIU, but has some
> dependencies and was a good exercise. The main work was to modify the
> Makefiles so that they can produce static archive libraries and replacing
> one glibc non-standard macro with the standard one.
>
> I am now working on producing a bootable USB flash disk with two
> partitions, one containing the kernel and the Syslinux bootloader files and
> one with the root filesystem containing Busybox-1.23.1, Vdevd and its
> helpers, and even  Bash, all statically linked against Musl. I tried to
> boot it 15mn ago but my kernel is still missing some drivers to be able to
> mount the usb key. I chose this configuration, rather than an initramfs, to
> be able to make persistent changes to my root filesystem, but it means that
> all the drivers needed to mount the root partition must be compiled in the
> kernel instead of loadable modules.
>
> I am very excited at seeing vdev in action and I don't think I will do
> anything else before I see if it works. Then I promised to Jude to send him
> the necessary patches. I think that, with the patched version of vdev, you
> could compile it statically with any ready-made gcc-musl toolchain (eg
> Sabotage). Could you wait a few days more?
>
> Didier


No problem waiting mate.
I even could try myself, did openssl static with musl a while ago but am
not a 100%
with what toolchain means.

did you compile for 32bit or 64bit?




> ___
> 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] A novice attempt to speed up Devuan development

2015-05-14 Thread Steve Litt
On Thu, 14 May 2015 22:15:50 +0200
Svante Signell  wrote:

> People are working _now_ on eudev as a replacement for udev until vdev
> is finished. It might even be a good replacement for udev already for
> the devuan jessie release. What do you do, except chat?

The best thing to do with those who "just chat" is to ignore them, and
if that's difficult pipe them to /dev/null. Ignoring them removes the
charge they get out of starting arguments, and greatly increases signal
to noise. If somebody repeatedly posts viewpoints adverse to the very
core beliefs of Mailing List A, when Mailing Lists B, C and D are
friendly to those same viewpoints, you know what his motive is, and can
send him packing by ignoring him.

I'm not saying this exclusively to you, Svante. I'm making a broader
point to everyone. There's a guy, whom I /dev/nulled years ago, who
for years has repeatedly dissed Linux and promoted Windows on the
oc...@mailman.oclug.org mailing list. Unfortunately, every time this
guy posts, five or ten regulars argue with his latest repeated
and perfectly predictable post, starting a big hoo-ha. And this is how
the Linux disser controls the ebb and flow of the OCLUG Linux mailing
list.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] A novice attempt to speed up Devuan development

2015-05-14 Thread Hendrik Boom
On Thu, May 14, 2015 at 10:15:50PM +0200, Svante Signell wrote:
> On Thu, 2015-05-14 at 12:15 -0500, T.J. Duchene wrote:
> > > I think the fact that I pointed out clearly shows that there is very good
> > > technical reason to exclude udev, unless you are willing to be the 
> > > maintainer
> > > of udev outside systemd source tree in Devuan.
> > 
> 
> > The shortest and most reasonable route to release a stable 1.0 of
> > Devuan is to use udev for the present.
> 
> See below.
> 
> >  Eudev might make a good
> > replacement, but udev is still the best candidate in terms of people
> > using it if you follow the principle that "eyes make bugs shallow".
> 
> People are working _now_ on eudev as a replacement for udev until vdev
> is finished. It might even be a good replacement for udev already for
> the devuan jessie release. What do you do, except chat?

Isn't eudev actually the systemd-free fork of udev everyone is asking for?

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


[Dng] Document on using Qemu for Linux DIY

2015-05-14 Thread Steve Litt
Hi all,

I just finished a very basic document on using Qemu for Linux DIY,
which I tech-edited using Valentines Devuan:

http://www.troubleshooters.com/linux/diy/qemu.htm

It's based on three shellscripts, and also contains instructions for
sharing host and guest /tmp/xfer directory via sshfs. As you know, Qemu
currently has no copy and paste between host and guest, so a shared
directory's a great way to transfer copied text or screenshots.

The shellscripts in this doc, perhaps modified by you, might be a
timesaver for some of you who are repeatedly testing Devuan. 

Hope you like it.

SteveT

Steve Litt 
May 2015 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Laurent Bercot

On 14/05/2015 23:16, shraptor shraptor wrote:

I even could try myself, did openssl static with musl a while ago but am not a 
100%
with what toolchain means.


 I compile everything statically with musl. OpenSSL is doable; the
annoying thing IIRC is the Perl dependency at build-time, and of
course the fact that OpenSSL is a bloated monster with one security
hole discovered every year, but it can be made to work.

 The best bang for your buck as far as toolchains are concerned are
the ones from Aboriginal Linux: pre-compiled, work, don't leak even
if there's a glibc on your machine. Look at
http://landley.net/aboriginal/downloads/binaries/root-filesystem/

 They're uClibc-based for now; Rob is working on porting them to musl
and he says it should happen in the next release. In the meantime,
I can still link my code against musl by tweaking the musl-gcc
wrapper and the .specs file - more details on demand.

 If you don't want to get your hands a bit dirty to make the
Aboriginal Linux toolchains work with musl (which is still nothing
compared to some other toolchains I've had the displeasure of working
with), the musl-cross ones, at http://musl.codu.org/ , also work -
the problem is I've never been able to find a *native* toolchain here,
so you're kinda stuck compiling for x86_64 using x86 gcc binaries.

 I can't stress enough how much time the Aboriginal toolchains have
saved me. For every attempt at linking software statically with
something less demented than the glibc, it's invaluable.

--
 Laurent

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


Re: [Dng] Document on using Qemu for Linux DIY

2015-05-14 Thread hellekin
On 05/14/2015 08:18 PM, Steve Litt wrote:
> 
> sharing host and guest /tmp/xfer directory via sshfs.
> 
*** I use the Plan9 way for sharing folders (per someone's suggestion on
the list):

https://git.devuan.org/devuan/devuan-project/wikis/try-devuan-on-qemu#sharing-a-folder-with-the-host

==
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] [dng] vdev status update (2015-05-03)

2015-05-14 Thread James Powell
There's no issues, but due to the variable in the way Slackware packages 
things, I have to create directories in the temp install, then use cp to 
installing things which ends up being messy.

Not to complain, but the lack of a traditional configure file to set the 
install paths does make things more hectic, especially with some of the config 
files and other shell scripts.

While unnecessary, yet, it does make packing vdev a bit more hectic.

Slackware uses a sort of fakeroot style packager, pkgtools, that creates a temp 
directory for source and one for the build output. It then uses configure to 
create $DEST set paths for installing into the temp directory before packaging.

It's not anything major needed, but it would help in the future, especially 
installing to /lib64 for the lib path instead of /lib which is symlinked on 
other 64-bit distros.

Sent from my Windows Phone

From: Jude Nelson
Sent: ‎5/‎14/‎2015 12:33 AM
To: James Powell
Cc: dng@lists.dyne.org
Subject: Re: [Dng] [dng] vdev status update (2015-05-03)

Hi James,
On Thu, May 14, 2015 at 12:04 AM, James Powell 
wrote:

>  Thanks Jude.
>
> The Slackware package is delayed, but only due to the lack of a Slackware
> style script. I might try to ask one of the Slackware team for assistance
> when I resume work. However, the package is fairly much completed in terms
> of installation points and directory setup.
>

Hey, that's pretty cool!  First the AUR packages (from Jack Frost aka
openfbt), now Slackware.

I'm not a Slackware or Arch user, but please let me know if there's
anything I can do to make packaging easier?  I don't want to make things
needlessly difficult :)

-Jude


> Sent from my Windows Phone
>  --
> From: Jude Nelson 
> Sent: 5/13/2015 8:24 PM
> To: dng@lists.dyne.org
> Subject: [Dng] [dng] vdev status update (2015-05-03)
>
>  Hey everyone,
>
>  I have the latest news for vdev:
>
> * vdev now creates symlinks for:
> -- /dev/v4l/by-path
> -- /dev/disk/by-partuuid
> -- /dev/disk/by-partlabel
>
>  Thank you Scooby for helping me confirm this!
>
>  * vdev now sets the proper ownership and permissions for:
>  -- /dev/mISDNtimer
> -- /dev/mwave
> -- /dev/parport[0-9]
> -- /dev/printer
> -- /dev/ppdev
> -- /dev/lp[0-9]
> -- /dev/irlpt[0-9]
> -- /dev/sch[0-9]
> -- /dev/pktcdvd[0-9]
> -- /dev/qft[0-9]
> -- /dev/zqft[0-9]
> -- /dev/nqft[0-9]
> -- /dev/nzqft[0-9]
> -- /dev/rawqft[0-9]
> -- /dev/nraqft[0-9]
> -- /dev/rawctl
> -- /dev/aoe
> -- /dev/lirc[0-9]
> -- /dev/legousbtower
> -- /dev/sonypi
> -- /dev/mmtimer
> -- /dev/sgi_*
> -- /dev/z90crypt
>
>  * Didier Kryn has gotten vdevd and vdevfs to statically link and compile
> with musl libc.  I'm looking forward to merging his contributions :)
>
>  * the build system has been refactored to use Makefiles more
> appropriately:
> -- every generated file gets written to a separate build/ directory
> -- every generated file is created by a non-phony target (i.e. nothing
> happens by side-effect)
> -- global buildconf.mk for setting variables
> Thanks to Didier again for the suggestion!
>
>  * the initramfs hook conditionally pulls in iproute2, lvm, dmsetup,
> blkid, etc.  Moreover, vdev's helpers conditionally use these programs if
> they are present.  This means that vdev doesn't strictly depend on them
> anymore, which is good if you're not using mapped devices or logical
> volumes.  Thanks to Anto for the suggestion!
>
> * the initramfs hook pulls in the correct GNU libc files now, so chown(1)
> will work correctly in the initramfs.  Thanks to Scooby, Isaac Dunham, Tom
> H for their help!
>
>
> [For Next Time]
>
>  * The next immediate objective is to package vdevd for Devuan, to make
> it easier to test (in particular, easier to get a working initramfs).  I'm
> currently dissecting udev's packaging and reading through Isaac's mdev
> scripts to see what to expect and what we can recycle.  I've never packaged
> something this complex before.  Thanks to Scooby, Anto, Tom H, and others
> for all their help on getting me this far!
>
>  * Symlinks and permissions for RAID devices (/dev/md[0-9] and friends).
> I don't run a RAID myself, so I'll need to go set one up in QEMU.  If
> someone wants to test vdev with a RAID, let me know, and I'll try to write
> a helper script to play around with sooner rather than later.
>
>  * In some distros and configurations, a separate device manager (like
> mdev) can populate just enough of /dev to mount root, but not try to set up
> any symlinks.  Vdevd must have a way for the admin to tell it to run helper
> scripts for the device even if its device node was already created
> (indicating that it has been set up), so the symlinks and permissions still
> get set appropriately.  Thanks to Scooby for reporting this!
>
>  Thanks,
> -Jude
>
___
Dng mailing list
Dng@lists.dyne.org
h

Re: [Dng] [dng] vdev status update (2015-05-03)

2015-05-14 Thread Didier Kryn



Le 14/05/2015 23:16, shraptor shraptor a écrit :

am not a 100%
with what toolchain means.

did you compile for 32bit or 64bit?

Toolchain generally means the stuff necessary to build new programs 
from source. It includes gcc, binutils, the system libraries, the system 
headers and the kernel headers. 'system', here, means the headers of the 
standard C library and the library itself, things that your default gcc 
searches automatically in /usr/include, /lib and /usr/lib unless you 
specify --nostdinc and --nostdlib.


I compile for x86_64 on x86_64. I tried to build a cross-compiler 
for powerpc, without success up to now and I also failed to build a 
native powerpc one.


My gcc-musl is "sysrooted", which means it searches the standard 
files in its own file tree and hence can live in the same host as Debian 
Wheezy's stock compiler. But I have noticed that many packages 
systematically add -I/usr/include in their CFLAGS, which is useless if 
you compile with the stock gcc and which fucks up the sysrooted one by 
including the headers of the glibc instead of the ones of musl. 
Therefore this is the first thing to check.



Le 15/05/2015 03:07, Laurent Bercot a écrit :

the
annoying thing IIRC is the Perl dependency at build-time,
I have built Perl, Miniperl and Python, statically linked against 
Musl. I don't understand a single word of these languages, but they are 
prerequisite to build other packages.



the problem is I've never been able to find a *native* toolchain here,
so you're kinda stuck compiling for x86_64 using x86 gcc binaries.


I think that's what I've done, on x86_64; it is all statically 
linked and, therefore, can be used right away on any Linux x86_64. And 
it can compile more than C and C++ :-)


I can produce a gcc-4.8 with it, but this one doesn't work.

Didier


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