Re: [Dng] About separate mailing lists

2015-02-11 Thread shraptor shraptor
I am not a dev at devuan but wants to have an ear in on what's going on

Would not be interested at all in user mailing list. Have had enough of
flame fights regarding systemd

Did contribute money to the cause

On Wed, Feb 11, 2015 at 6:56 PM, Jack L. Frost  wrote:

> On Wed, Feb 11, 2015 at 11:59:03AM -0500, Steve Litt wrote:
> > Devuan Weekly News XI posed the following question:
> >
> > ==
> > Talking about something else, it seems that the list is becoming
> > two-fold. On one hand, it becomes concentrated on development, while
> > at the same time it discusses more philosophical issues. Maybe is it
> > the moment to separate into a dev list and a users list?
> > ==
>
> Weighing in a bit:
> Separation of a mailing list (or any other community tool) should be
> considered
> when said tool becomes too hard to manage. dng is not even lkml yet,
> separating
> it into several mailing lists would drastically slow discussions down and
> unnecessarily split people up.
>
> ___
> 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] pre-alpha live iso

2015-03-01 Thread shraptor shraptor
On Sun, Mar 1, 2015 at 2:31 AM, Go Linux  wrote:

> fsmithred over at Refracta created a live iso of the valentine's pre-alpha
> with refractasnapshot.  He said I could post a link here for those who want
> to check it out but don't want to install.
>
> http://distro.ibiblio.org/refracta/files/other/


Tested LiveCD unofficial-live-20150227_0355.iso
Booted with Easy2boot on usb stick.

Boots with no discernable problem, root password hacked at third attempt
after trying "root", "debian"

Problems with wireless allthough iwlwifi seemed to be loaded I could not
get wlan0 interface
Have errors in dmessg reagrding this. Missing interface. Problem for later.

Found the old ethernet cable in the closet and got IP

No browser so rebooted and downloaded opera static from my usual linux
which is arch based so I have no prior knowledge to debian.

The link is
http://sourceforge.net/projects/portable/files/Opera%2011.50/download
can be wget'ed

tried my hand at apt-get:
apt-get update  # works but seems to ignore a lot of debian repos, probably
a feature, right

apt-get upgrade # Something did happen: mount util-linux upgraded

apt-get install * # where * denotes what I tried like firefox and so on
failed
 # probably doesn't have repo setup



No problem mounting any media ntfs, FAT32, ext, BTRFS


reboot worked but showed some warning or errors


All in all it seems pretty solid in this pre-alpha state
I have good hopes for the future

Keep up the good work

Best regards

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


Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds

2015-03-04 Thread shraptor shraptor
I would like to remind you that nobody was
born a great coder but through misstakes
learned to be better.

I think some coders that write crappy code
are on their way to be great. others have
a hidden agenda and theres a difference.

I consider myself of moderate coding skills
and I like shell. I learnt coding in basic, modula2 and some c.

Sometimes its hard to find time to write good code at least when you got
another job.

What about vala or does it automatically fall
in the c language catagory

On Wednesday, March 4, 2015, KatolaZ  wrote:

> On Tue, Mar 03, 2015 at 04:42:42PM -0600, T.J. Duchene wrote:
> > On Tue, 3 Mar 2015 07:25:23 +
> > KatolaZ > wrote:
> >
> >
> > > Well, if you found that *for your particular tasks* C can replace Perl
> > > or Python, I believe you. But it's just not true that this should be
> > > the case for everybody else, in every possible use case.
> > >
> >
> > What I have found is that many of the arguments surrounding the
> > particular choice of "this language is better for task A, while this one
> > is better for task B" is very subjective and often entirely false.
> >
>
> Well, being "subjective" does not automatically imply "being
> false". IMHO, as with all other creative activities, programming is
> all about background, knowledge, taste, mood, weather conditions, and
> millions of other *subjective* factors. And when you choose a language
> these subjective factors will have some relevance and count.
>
> I won't ever consider JAVA for anything serious, despite I think I
> used to know that language to a sufficient proficiency level. My
> repulsion is based just on personal *subjective* factors, not on any
> technical consideration or efficiency evaluation. And this will not
> change even if you show me with convincing scientific evidence that
> JAVA is the best possible language for every possible application you
> might ever need to code. I will not use it anyway :)
>
>
> A completely different story is being able to write *good* code, which
> is normally not strongly related with the language you use. If you are
> a good coder, you will always spit out good code in LISP, javascript,
> pascal, fortran, C, haskell or whatever. If you are an asshole of a
> coder, you will unavoidably vomit garbage, whatever fancy language you
> will end up using... No language will save you. There is a *huge* lot
> of very bad C code out there, and not because C is a bad language or
> enforces bad programming habits or avoids good practices. Just because
> there are far many more assholes than good coders, IMHO.
>
>
> My2Cents
>
> KatolaZ
>
> --
> [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
> [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
> [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
> [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
> ___
> 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] Plan for Devuan to use Mozilla products as is

2015-03-05 Thread shraptor shraptor
On Thursday, March 5, 2015, Jude Nelson  wrote:

> > Besides issues related to Chromium's poor support for privacy features,
> > it also has no real security support.
>
> No comment on the privacy features, but I beg to differ on the security.
> The fact that the Linux build of Chromium runs each tab and plugin in its
> own seccomp'ed process and runs them all separately from a "kernel" process
> puts the browser worlds ahead of Firefox in terms of security.  Excluding
> project Electrolysis (which I look forward to), the fact that Firefox runs
> every tab in the same process means that one bad tab can compromise the
> whole browser without too much effort.
>

Tried e10 in nightly-builds, a lot of tab-crashing.

I however use firejail to sandbox/seccomp
firefox - works great. When namespaces gets properly included I hope it
would be hard to gain root.

I don't trust anything google
I like icecat




> By contrast, Chromium's kernel/process-per-tab factoring has led to secure
> browser designs [1] where this class of exploit and others are provably
> impossible.
>
> -Jude
>
> [1] http://goto.ucsd.edu/quark/
>
>
> On Wed, Mar 4, 2015 at 8:33 PM, Adam Borowski  > wrote:
>
>> On Wed, Mar 04, 2015 at 05:14:26PM -0600, T.J. Duchene wrote:
>> > >>>Is Devuan going to use the exact same guideline? If not,is there any
>> > >>>plan for Devuan to use Mozilla products as is in the future,
>> > >>>especially Firefox and Thunderbird?
>> >
>> > If I might offer an alternative suggestion?  I'd rather see Devuan
>> > default to Chromium with NAPI support than use Firefox, period.
>>
>> Besides issues related to Chromium's poor support for privacy features,
>> it also has no real security support.  There's nothing but "install the
>> newest and greatest, right now".  Unlike Firefox' long-term-support
>> releases, any version of Chromium becomes unsupported the moment a new one
>> appears.  Even worse, there's no heed that such new version builds on
>> toolchains which are not likewise "newest and greatest" (such as gcc-4.7).
>>
>> Please read:
>> https://lists.debian.org/debian-security-announce/2015/msg00031.html
>> -- there is no security support for Chromium on any Debian release:
>> support
>> on wheezy had to be dropped, while there's no jessie yet, and wheezy has
>> still 1.5 years of primary security support, not to even mention LTS.
>>
>> --
>> // If you believe in so-called "intellectual property", please immediately
>> // cease using counterfeit alphabets.  Instead, contact the nearest temple
>> // of Amon, whose priests will provide you with scribal services for all
>> // your writing needs, for Reasonable and Non-Discriminatory prices.
>> ___
>> 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] Puppy Linux, AntiX - was Re: Puppy Linux-related thoughts

2015-03-25 Thread shraptor shraptor
renaming root account does not leverage increased security in my opinion

It would be easy to find out new name of the "superuser"

So whats the advantage to rename root?

I run a puppy linux kind of os and automatically login as root, desktop
user
But I run critical applications as web-bowsers in a secured environment
using firejail - a kind of sandbox

As I understand it will in future releases implement --noroot that is
you cannot become root in that sandbox.

Every software can be hacked via bugs of course but hopefully
it wil make it harder for tha hacker

best regards

Scooby





On Wed, Mar 25, 2015 at 2:35 PM, Martijn Dekkers <
devuan-li...@dekkers.org.uk> wrote:

>
> What are the security problems with IRC?  I use it to chat in ASCII and
>> make a log.  Evidently it has other, more dangerous capabilities I'm
>> not aware of.
>>
> https://www.google.com/search?q=irc+client+exploit
>
> Are there any drawbacks to naming the root account something other
>> than 'root'?  Perhaps by editing /etc/password and /etc/shadow? And, of
>> course, renaming /root correspondingly?
>
>
> I understand that the general consensus is "don't do it, it will break
> stuff" as many services and tools could depend on a root account being
> present.
>
>
>
> ___
> 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] libudev-compat

2015-03-28 Thread shraptor shraptor
Is libudev-compat ready for testing?
I saw jude had committed some code.

Was there any testing done on vagrant image?

best regards

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


Re: [Dng] Claim your power

2015-03-31 Thread shraptor shraptor
I wouldn't say systemd developers are evil
merely selfish

On Tuesday, March 31, 2015, Martin Steigerwald  wrote:

> Hi!
>
> As a honest feedback:
>
> Currently I do not read much of the threads here.
>
> Cause again and again I see language like systemd being like a cancer or
> infecting people´s systems.
>
> It is neither a cancer, nor does it infect systems.
>
> What this kind of language mirrors in my eyes is fear of having to put up
> with systemd at some point.
>
> Yet, at any time it has been upstream developers or package maintainers
> who *decided* to adopt it.
>
>
> Saying that systemd is the source of all evil and we are doomed to it, is
> in no way helpful for any "we want to be without systemd" efforts like
> Devuan. Quite the opposite: It harms the credibility of such projects,
> cause it gives the impression that those projects just consists of a bunch
> of people who circulate conspirations theories about systemd *without*
> doing *anything* about the situation.
>
>
> So here is my plea to stay to what you actually *really* perceive. Stop
> assuming intentions. Especially stop assuming bad intentions. I think that
> systemd developers essentially mean it good. They have no evil plans to
> take over the world or do harm to others. Instead they believe that what
> they do is worthwhile.
>
> Of course its totally and perfectly okay not to agree with that.
>
>
> But please stop assuming intentions that may or may not be there. And for
> your own benefit, stop using a language which gives your power away.
>
> systemd is no cancer and it does not infect systems.
>
> If systemd is on your system, either you installed it or upgraded it and
> your distro package maintainers decided to use it.
>
> So systemd developers, if you agree with it or not, had quite some success
> in convincing others to use and rely on systemd.
>
>
> Yet this is exactly what makes Devuan possible:
>
> If you put some effort to it, like for example Jude does without engaging
> much into the fear based threads so far as I have seen, *it is perfectly
> possible to have a system without systemd*.
>
> And no systemd whatsoever would infect such a system. It just doesn´t have
> the power to do it. Its a piece of code. It has no power whatsoever on its
> own. Its no evil critter which just sits next to computer and waits for a
> chance to take it over.
>
> And if you are constructive and positive in your approach, and your
> systems provides a good alternative, then more may adopt it in the future.
>
>
> Yes, some upstream developers decided to rely on functionality provided by
> systemd and some depend on it, instead of making it optional. And yes, I
> see this development with concern. But it is still a decision. No
> automatic effect.
>
> systemd has absolutely and totally *no* power over you.
>
> systemd upstream has absolutely and totally *no* power over you.
>
> I want to repeat this:
>
> Neither systemd nor systemd upstream have any power over you.
>
>
> This is still *free* software.
>
>
> Stop giving your power away.
>
> Instead: Claim it. Claim it by using a language that is free of self-
> defeating patterns like that. A language that puts back the responsibility
> in your hands.
>
> Feel your fear, appreciate it, and by that unlock the power you locked
> down in it.
>
> You have any power in the world to support any efforts to have a systemd
> free system.
>
> So now choose: In what way do you want to spend your energy?
>
>
> Did any of the talk about systemd being a cancer or infecting people´s
> system do *any* good to change the situation? Did it work? Or do efforts
> like the one of Jude with vdev any good to change the situation? Does it
> work?
>
> Do more of what works, and instead of repeating patterns that are
> ineffective in changing your current situation, do something that works as
> well.
>
> Or if you do not want to invest the time, let others do it and be grateful
> about it instead of filling this list with powerless and self-defeating
> thought patterns.
>
>
> (That said I think cancer usually is no death sentence either and there
> are quite powerful approaches in addition or as alternative to academic
> medicine to deal with it. And I believe that there are ways to help the
> body to deal with any kind of infection.)
>
> Ciao,
> --
> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
> ___
> 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] Update from the Veteran Unix Admins

2015-04-01 Thread shraptor shraptor
A good laugh at the funds should support
Kay Sievers kernel push

ha ha

On Wednesday, April 1, 2015, Veteran Unix Admins 
wrote:

>
> Dear Init Freedom lovers,
>
> Once again the Veteran Unix Admin collective salutes you!
>
> As most of you know, we have followed up with our intentions in
> developing Devuan GNU/Linux right after Ian Jackson's GR vote resolution
> in Debian. We have made great progress and achieved several milestones
> among them a complete SDK to facilitate package maintainance, a new
> package repository software "Amprolla" and a continuous integration
> workflow based on gitlab and Jenkins. We are also proud to have
> facilitate the work of Jude Nelson on a new /dev daemon implementation
> called VDev and more in general to have given voice to all those who had
> doubts about systemd being a viable course of evolution for GNU/Linux
> operating systems.
>
>
> By doing so we have obviously looked deep inside Debian and systemd
> itself and we have never refrained from critically analysing what
> systemd was doing as well what we were doing and the reasons for it.
>
> We firmly believe every responsible and critical engineer out there
> should at least think twice about developing something new systems and
> even Donald Knuth teaches us in the Art of Programming that is always
> appropriate to re-think and re-design algorithms and challenge ourselves
> over our own initial beliefs.
>
>
> That's why today, after 7 months of work in the direction of forking
> Debian we have decided that not, we will not do that.  Today we give up
> and we accept to be assimilated.  After all, we think that systemd is
> not so bad and we can live with it.
>
> We understand some of you may not be convinced, but please consider our
> decision here is really well thought. It is also too hard for us to
> catch up with the rampant development going on in systemd and we believe
> that we can live just fine with systemd and some shims. We tried hard,
> now we hope you will believe us and even if you don't, at least please
> give systemd a try.
>
> With the existing infrastructure in place, we will start maintaining a
> mirror of systemd and use our CI infrastructure to contribute
> deterministic reproducible builds of Debian packages.
>
> We ask the free and open source software community at large to please
> accept our apologies for making so much noise on this issue, today we
> feel like we have just been trolled by all those complainers we
> initially gave voice and leverage, while it is evident they have nothing
> to contribute really. It took us some time to understand that systemd is
> the future and we hope this experience contributes to a critical
> understanding of systemd.
>
> To all those who have donated substantial amounts of money so far: we
> commit to return you all the donations in EUR or Dogecoin. The donations
> that cannot be returned will be used for a petition campaign to give
> back Kay Sievers access to push modifications to the Linux kernel, as
> well to distribute the upcoming O'Reilly book on systemd to poor
> children in Africa.
>
> so long and thanks for all the fish,
>
> The Veteran Unix Admins
>
>
> ___
> 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] [dng] vdev status update

2015-04-07 Thread shraptor shraptor
Scooby, John Carline, lepoitr, and others (who wish to remain anonymous)
> have been sending me logs filesystem listings from running vdev locally.  I
> very much appreciate it--it helped me discover and fix bugs relating to
> persistent paths for disk devices, seeding /dev with initial device files,
> and adding support for Virtualbox USB devices.  Thank you to everyone who
> helped me with this!
>

Thank you for taking on this hard task



> However, this has proven to be a somewhat challenging problem, for a
> couple reasons.  First, inotify(2) does not work on pseudo-filesystems like
> sysfs or devtmpfs, so we can't just watch /sys for changes, and we can't
> use devtmpfs for /dev.  This means that systems using libudev-compat will
> require a "vanilla" tmpfs for /dev (or nothing at all), so it can detect
> when devices are added or removed.  Second, only block and character
> devices show up in /dev.  However, udevd reports every kind of device,
> since it listens to the kernel's driver core (i.e. libudev learns about
> network interfaces, buses, power supplies, etc.--stuff for which there are
> no device files).  Clients will expect this behavior, so it's not enough to
> simply look up a new block/character device's sysfs data.
>

Is this "listen to  kernel driver core" something you don't want to do? If
so is it because one of the project goals
is to support several platforms i.e BSD?

Or is it to keep it modular and not so interdependent?



> My tentative solution is to require the device manager (whatever it
> happens to be) to take one extra step in addition to adding/removing device
> files: record driver core uevents in a well-defined location in /dev (let's
> say /dev/uevents/), so libudev clients can discover them (with inotify(2)),
> read them, and send them off to their applications.  This can be done
> without loss of generality in udev, vdev, and mdev, and I can make a script
> that takes the appropriate action with mknod (so those with a static /dev
> can alias "mknod" to the script, if desired).
>

So you want to split up the "listen to kernel driver core uevents" part and
vdev right?

Trying to figure this out

I saw you mentioning Isaac Dunham's libsysdev in another message.
It is a replacement for libudev, right?

Can libsysdev do this part quoted below?

"report every kind of device, since it listens to the kernel's driver core
(i.e. libudev learns about network interfaces, buses, power supplies,
etc.--stuff for which there are no device files"

Is vdev and libsysdev tested together?


>
>
To avoid the troublesome corner case where a libudev client crashes and
> potentially leaves behind a directory in /dev/uevents/, I would recommend
> mounting runfs [1] on /dev/uevents.  Runfs is a special FUSE filesystem I
> wrote a while back that ensures that the files created in it by a
> particular process get automatically unlinked when that process dies (it
> was originally meant for holding PID files).
>


I tried runfs on my system that is using aufs and couldn't get it to run
I got something like "Transport endpoint is not connected"
This is not a problem for me since dev/ won't be persistent between boots
so can run without runfs.

best regards

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


Re: [Dng] Would like to help with Devuan

2015-04-08 Thread shraptor shraptor
Reading can get you a bit on the way
but it's better to start hacking.

At least for me I think is where I learn best.

pick some project that interest you and start
there. I think its better to do something that
is important to yourself in the beginning.

On Wednesday, April 8, 2015, JeremyBekka C  wrote:

> Hello,
>
>  I hope this is the right place to post this question, but I am looking
> for some advice on how to gain the necessary technical skills to help with
> future development of Devuan.
>
>
>  I am relatively new to Linux (2 years) and to computing in general.
> Prior to starting in Linux, I had just a rudimentary knowledge of computers
> (just from running Windows and building my own computer from parts bought
> online), but I have learned a lot of the last 2 years through working with
> Linux. I have read William E. Shotts book The Linux Command Line, and I
> also earned a Verified Certificate from the Linux Foundation by taking the
> Introduction to Linux class at www.edx.org. I am currently trying to
> learn Python through an online tutorial at http://www.learnpython.org/.
>
>
>  The reason why I would like to help with Devuan is because I really love
> Linux and am sad to see what is being done to it by RedHat and systemd.
> Last year I was really discouraged because I felt like I had discovered
> Linux to late and now all that I loved about it was going away. So, it was
> a real encouragement to see the VUA and their announcement about Devuan. I
> understand the difference between Open Source and Free Software and would
> like to be a part of a community like Devuan that values the freedom of its
> users.
>
>
>  I know that I have a lot to learn, especially after reading the
> technical posts here about the development of Devuan, but I am motivated
> and want to learn. There is so much out there to read that I am overwhelmed
> sometimes and don't really know where to start. There are so many man pages
> that I really don't know which ones are the most important ones to read
> first. So, I am wondering if I could get some tips on what I need to learn
> and how I can go about getting the proper training to be of service here in
> the Devuan community. I would like to be able to help detect and fix bugs,
> and maybe become a package manager someday.
>
>
> Thanks for your advice,
>
>
>  Jeremy
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [Dng] dev-list

2015-04-08 Thread shraptor shraptor
I would be on both lists

Sometimes I enjoy the chatter and sometimes I press delete





On Wednesday, April 8, 2015, Martin Steigerwald  wrote:

> Am Mittwoch, 8. April 2015, 08:09:14 schrieb Robert Storey:
> > > Good point.  But I thought the reason for the suggestion was because
> > > of
> > > the amount of fairly useless chatter on this list that the devs have
> > > to
> >
> > wade
> >
> > > through.  (Honestly, it annoys me too.)  If there is a -dev list, I
> > > would
> > sign up
> >
> > > to see what's happening but it's unlikely I would participate because
> > > I'm not really qualified to do so.
> >
> > All good points. Just want to add though that probably one of the causes
> > of all the idle chatter is that we in the audience don't yet have
> > Devuan in our hot little hands, so we have no technical questions, no
> > bug reports, etc. All we can do for entertainment chat about what
> > Richard Stallman thinks of systemd, suggest that Pottering is evil, and
> > enquire about when Devuan-alpha will be released. I try to avoid those
> > silly discussions, but have occasionally broken down and participated.
> >
> > Once we have the alpha in our hot little hands, we can begin to discuss
> > the real technology, and stop wasting developers' time with trivia. And
> > I may finally start my long-awaited project to help writing the
> > documentation.
>
> Seriously?
>
> Then I´d suggest creating a "I am bored and want to talk about trivia"
> kind of mailinglist. Or a course in meditation to be able to deal with
> some silence in between.
>
> I still hardly read the list due for the reasons I already explained which
> are similar reasons why I unsubscribed debian-user: The noise to useful
> content ratio is so high that I feel it to be like a waste of time to try
> to find the interesting messages in between in most threads.
>
> So for now, I just check, is it Jude posting vdev news, read that, and,
> honestly mostly forget about the rest. I can deal with it like that, my
> mail program can as well, but this way I may miss some of the mails that
> have useful content.
>
> Heck, I don´t even expect every mail to be useful for me. But a bit better
> ratio, that would be good. So please, if you just post here out of
> boredom:
>
> Stop!
>
> And use your boredom as a chance for personal development.
>
> Thanks,
> --
> Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
> GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
> ___
> 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] Live ISO's (Jessie with no systemd)

2015-04-14 Thread shraptor shraptor
Does debian livecd's use linux live kit
by slax developer Thomas Matijeck?

I remember I saw on slax forum he was
contracted by debian to do some work
on livecd? true or false??

On Monday, April 13, 2015, fsmithred > wrote:

> On 04/13/2015 03:00 PM, Richard wrote:
> > Thanks Fred,
> > David's snapshot is working very well for the most part.
> > A real credit to it's Refracta base. Couple of questions:
> >
> > 1. fstab is 0 bytes? But seems to work.
> > Where is the info kept, in Jessie?
> >
>
> It's a live iso. No disks to mount. The live-config scripts handle it, and
> when it's running, you'll see aufs and tmpfs in fstab. (Look in
> /lib/live/config and /lib/live/boot if you want to see the scripts.)
>
>
>
> > *2. # sudo apt-get update*  failed,
> > reporting conflicting distros ... (expected sid but got ceres);
> > also NO_PUBKEY. Just for information, I know it's still fresh.
>
> Can't help with that. I haven't looked at the sources.list yet.
>
> fsr
>
>
> >
> > regards,
> > Richard.
> >
>
> ___
> 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] Which package generates /lib/systemd and /etc/systemd files?

2015-05-05 Thread shraptor shraptor
But I guess there is no obstacle to for instance run vdev with systemd, huh?

On Tue, May 5, 2015 at 7:33 PM, Jaromil  wrote:

>
> dear Noel,
>
> I'm happy that you are back, we really miss DWN, but I'm also sorry to
> contradict you on this one.
>
> On Tue, 05 May 2015, Noel Torres wrote:
> > As a resume: If you want a systemd-free system, Devuan is your
> > distribution, and will always be. But if you want a system designed to
> > be unable to run systemd, please leave us. This is not the place for
> > such an anti-freedom POV.
>
> perhaps we could say it was to simplify the transition, but in operating
> on packages so far we have removed systemd and the possibility to run it
> on Devuan, which is now as far as that of running sysvinit on Debian for
> normal users. This is more of a consequence of how Debian imposed
> systemd than a deliberate choice from our side. I personally agree with
> your line about init-freedom, but less agree with the line of telling
> people this is not their place especially if they look for a
> systemd-free system for whatever reason they have.
>
> At the inception of Devuan we have analysed the tradeoff of keeping
> systemd optional and thought it was too much work in a direction we
> weren't interested: we recommend Debian as the system of choice for
> those wanting to have systemd crippl*cough*cough*manage their computers.
>
> As simple as this, the result is that there is no option to have systemd
> in Devuan now and the simpliest way to have it would be anyway to use
> Debian. I'm not sure it will be ever a priority to get systemd back as
> optional for Devuan. Perhaps init-freedom is really realized by a
> plurality of distributions and if there is a merit for Devan is still
> that of preserving this freedom by providing an OS that is open to every
> init system *but systemd* since the latter does exclude anyone else by
> an enormous network of dependencies. In the future we'll invest efforts
> in supporting sysvinit and more init systems our there (OpenRC, DMD
> etc.) thus we'll be a bit more "universal" than Debian.
>
> Again personally I think that is an arrogant move today for any OS to
> declare itself "universal" as init-freedom and more freedom in the
> future is really realized by a plurality of distributions, a lesson we
> learn from this fork perhaps.
>
> ciao
>
>
>
> ___
> 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] [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 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


[Dng] systemd has a long reach

2015-05-19 Thread shraptor

Bought a jolla phone to replace my iphone.

Got trouble with mobile internet.

I have filebrowser installed.

Looking in /var/log

No text logs but got a textfile saying use journalctl

Probably is a way to get a terminal but I didn't know how
and had no Internet to research.

systemd has got a long reach indeed

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


Re: [Dng] automounting in a window manager

2015-06-01 Thread shraptor

On 2015-06-01 16:22, Rob Owens wrote:

- Original Message -

From: "Robert Storey" 

First, thanks to all who replied.

To me, the ideal solution would be if this was a user-configurable 
option.
Would be great if you could, for example, just stick something into 
.bashrc
for any user to allow automounting of USB devices, no matter which DE 
or
window manager was being used. But I know it doesn't work that way. 
Just

saying, it would make sense.

pmount - yes, thanks for reminding me. I've used it eons ago. But all 
it does

is allow one to mount a device without needing sudo. Still not really
automounting.

No one mentioned udevil. I just found it. Also not the same as 
automounting,

but check out the interesting git home page:

https://ignorantguru.github.io/udevil/

That guy also wrote spacefm.  It's a file manager which allows you to 
either
manually or automatically mount USB devices.  It can be configured to 
use

udevil, pmount, udisks1, or udisks2 to perform that function.

Spacefm is currently unsupported by the developer.




checking github
https://github.com/IgnorantGuru/spacefm/commits/next

it seems spacefm is very much alive




In the past I've used pcmanfm to perform this function, but on Jessie, 
it

seems to require systemd stuff in order to handle mounting.

-Rob
___
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 nice candidate substitute to network-manager

2015-06-15 Thread shraptor

I have used Connman on my arch derivative OS
never liked it

I use the Puppy Linux program pEasyWifi and likes it very much.
http://www.murga-linux.com/puppy/viewtopic.php?t=94501

Don't know if it gots every wanted feature though??

It is lightweight!

uses: GtkDialog, Xdialog, wpa_supplicant, dhcpcd, ifconfig, ??


Connman works OK on my jolla though :-)


On 2015-06-12 15:32, tigges wrote:

Jolla uses Connman and had a lot of trouble..

https://together.jolla.com/questions/scope:all/sort:votes-desc/tags:connman/page:1/

And for the AMD guy, Sailfish runs on ARM so it seems to be portable :D

Greetz

Tigges

___
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 update: performance, bugfixes, and udev events

2015-07-07 Thread shraptor

On 2015-07-07 17:45, Jude Nelson wrote:

Hey everyone,

I have the latest news for vdev:

* [EXPERIMENTAL] Vdevd now has actions and helpers that will cause it
to generate and propagate device events to libudev-compat clients. 
Libudev-compat clients should receive hotplug events as they would
have with libudev, and they should be able to enumerate devices. 
This means that it should be possible now to run X11 with vdevd and
libudev-compat, without needing an xorg.conf.  To do so, you'll need
to symlink vdev's /dev/metadata/udev to /run/udev.


CONFIRMED WORKING - a great milestone Jude, F***ing good work!

Both keyboard and mouse working without Xorg.conf  :-)

When inserting flash memory sticks they get autodetected and device 
nodes created :-)


Question This is working without a value for
/proc/sys/kernel/hotplug so it is not used and
only for udev???




* Hardware database access performance has been significantly
improved, and made more accurate (i.e. it should now match all
prefixes against the device modalias, not just the longest one).  By
"significant", I mean by an order of magnitude.

* As an optimization, vdevd can now run specially-crafted helper
scripts as "daemonlets."  Instead of fork()/exec()'ing a shell for
each action, vdevd will instead fork() an action's command once and
feed it a sequence of device requests, encoded as a list of
environment variables.  When running as a daemonlet, the command will
be expected to run a loop that will parse the request from vdevd, call
the command's main body of code, and report back the "exit" status. 
The heavyweight scripts (i.e. the ones that benefit from this) have
all been turned into daemonlets in this round of commits.  This leads
to around 25% performance improvement (on average) for each command.

* vdevd now benchmarks its actions, and writes performance information
to its logfile at the end of coldplug processing.  Just to give a
reference frame:  vdevd currently takes about 9 seconds to
cold-process all of my laptop's hardware (i.e. it's slower than udev,
but not that much slower).

* libvdev is no longer a build target.  Its code will instead be
statically linked to vdevd and vdevfs. This is to make installation
and deployment easier.  There's no real loss to doing so--the library
isn't that big in the first place, and the only programs that will
ever use it are vdevd and vdevfs (note that libvdev is not at all
related to libudev).

* Bugfixes:
-- the pre-seed script that runs before coldplug device processing can
now create device nodes, and signal to vdevd to run the associated
helper scripts anyway.
-- the pre-seed script will select the first free loop device (with
losetup -f) for the hardware database.
-- [NEEDS CONFIRMATION] the ifname.sh script should select the correct
config file now.  I'm still chasing down a "Device or resource busy"
bug in renaming interface names, so please keep your eye out for it.
-- [NEEDS CONFIRMATION] the disk.sh helper should now generate
/dev/disk for USB disks.

Thanks to everyone who helped me test vdevd so far!
-Jude
___
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 update: performance, bugfixes, and udev events

2015-07-07 Thread shraptor

On 2015-07-07 21:39, ibid...@gmail.com wrote:

On Tue, Jul 07, 2015 at 07:40:51PM +0200, shraptor wrote:

On 2015-07-07 17:45, Jude Nelson wrote:
>Hey everyone,
>
>I have the latest news for vdev:
>
>* [EXPERIMENTAL] Vdevd now has actions and helpers that will cause it
>to generate and propagate device events to libudev-compat clients. 
>Libudev-compat clients should receive hotplug events as they would
>have with libudev, and they should be able to enumerate devices. 
>This means that it should be possible now to run X11 with vdevd and
>libudev-compat, without needing an xorg.conf.  To do so, you'll need
>to symlink vdev's /dev/metadata/udev to /run/udev.

CONFIRMED WORKING - a great milestone Jude, F***ing good work!

Both keyboard and mouse working without Xorg.conf  :-)

When inserting flash memory sticks they get autodetected and device
nodes created :-)


I presume that this is not over devtmpfs, so you know it's vdev.



When I ran previous version of vdev this did not happen
so yes it is this iteration of vdev that does the job :-)

Other parts of my system was not touched when I upgraded :-)

I have no devtmpfs mounted :-)

Thanks for other info!


Question This is working without a value for
/proc/sys/kernel/hotplug so it is not used and
only for udev???


Linux handles hotplug events in multiple ways:

- /proc/sys/kernel/hotplug (aka "hotplug helper"):
 On each hotplug event, the kernel starts the hotplug helper with
 an appropriate environment.
 hotplug, hotplug2, and mdev/smdev use this.

- netlink:
 A daemon connects to the kernel and listens for hotplug events.
 udev, s6-devd, nldev, and vdev use this.

- devtmpfs:
 The kernel maintains a filesystem in RAM containing all devices that
 are present, and at hotplug the kernel automatically adds a new device
 with default permissions and name.
 This can sometimes be used alone; udev and perhaps Android's hotplug
 solution rely on this and change the permissions/owners/... after the
 fact.

Hopefully that clarifies things for you.


Thanks,
Isaac Dunham

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


Re: [DNG] Congratulations to the Devuan team

2015-08-12 Thread shraptor

Vdev is now in a functional state and I use it on
my desktop everyday.

vdev is now doing everything I used udev for.

I however don't use it in initramfs where I use busybox mdev.

More testers would probably be good for more use-cases so
agreed now packaging would be desired.

But as I said before vdev(libudev-compat) + spacefm auto-detection of
plugged devices is working for me. I don't want automounting but I
believe it would be easy to setup with udevil!?


/Scooby


On 2015-08-12 12:48, James Powell wrote:

We all know Devuan is going to create a huge ripple in the great big
pond, and join the ranks of the pro-choicers in regards to software
usage.

 While I'm following vdev closely, mostly to backport it to another
distribution, Devuan's success will bring success to other choice
giving distributions as well.

 It's a win-win situation finally.

 -Jim

-
 From: tilt!
 Sent: ‎8/‎12/‎2015 3:39 AM
 To: dng@lists.dyne.org
 Subject: [DNG] Congratulations to the Devuan team

Hi,

 I would like to convey my respect and appreciation to all
participants,
 acknowledging that Devuan GNU/Linux is in use here now as a
functional
 Linux Desktop which I use for tasks of software development and
system
 integration as well as for everyday mail, office and web stuff.

 Good work! Keep it coming!

 I definately look forward to vdev. Currently I try to involve myself
 in testing it out a bit; it appears like a very elegant solution that
 opens many interesting possibilities. I also heard that there is a
 packaging effort, and I wonder how that is coming along.

 I admit that in spite of issues I expressed previously on this list,
 I currently use PolicyKit to enable some "administrative operations"
 when using the system via XFCE4, simply because it's currently the
 easiest way for me to do stuff like mounting hot-plugged disks or
 managing libvirt guests.

 But that clearly demonstrates the paradigm of "freedom of choice"
 being successfully implemented in Devuan, where I can now freely
 choose system components that serve my needs best.

 Kind regards,
 T.
 ___
 Dng mailing list
 Dng@lists.dyne.org
 https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng [1]


Links:
--
[1] 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] Congratulations to the Devuan team

2015-08-14 Thread shraptor

I would help you mate but my install is a package
to be overlaid using aufs.

I have never used debian so would be a poor choice
in making a package for it.

I don't know how to turn off udev in debian.
I know Jude did some magic with that.

If you try to go at it manually I am willing
to offer help.

/Scooby



On 20lite 15-08-13 04:30, Robert Storey wrote:

About vdev...

It looks like it's almost ready for prime time, but that further
testing is needed to work out any bugs. So I'd like to throw out a
little suggestion to expedite that.

Could someone come up with a package so that we can install vdev on
Debian? In my case, I'm currently using antiX as my stable operating
system. I would be willing to install vdev on it and put it through
its paces, reporting back any suspected bugs I encounter.

Barring a specific package, then maybe some published instructions and
a download for installing it on Debian.

It sounds to me like vdev could be a game changer, so I'm enthused
about installing it and doing what I can to make it a new standard.

As I've mentioned before, I do occasionally write for DistroWatch, so
if I can get a positive experience with vdev, I'd do an article on
that. Hopefully, this would encourage others to download and install
vdev, helping to move along its widespread adoption.

Kudos to all the Devuan developers.

 - Robert


___
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 Shims

2015-08-15 Thread shraptor

I would be interested in

* No-dbus replacement for NetworkManager/Wicd

Are you thinking a C program?

daemon and user interface/GUI separation?


On 2015-08-15 18:01, Steve Litt wrote:

On Sat, 15 Aug 2015 08:51:55 +0200
Didier Kryn  wrote:


Le 15/08/2015 02:26, Steve Litt a écrit :
> On Fri, 14 Aug 2015 14:49:17 -0700
> Go Linux  wrote:
>
>> On Fri, 8/14/15, T.J. Duchene  wrote:
>>
>>   Subject: Re: [DNG] Systemd Shims
>>   To: dng@lists.dyne.org
>>   Date: Friday, August 14, 2015, 2:47 PM
>>
>>> I know not everyone here agrees with me, especially Steve, and
>>> that's perfectly okay.  I have no problem with that at all. I just
>>> don't see "System 5 pure"  as realistic when planning ahead
>>> looking at a maintenance standpoint when Debuan upstream is more
>>> and more likely to stick with Systemd in designing their
>>> packaging.
>>>
>> Maybe we should just put Steve in charge of decontaminating all
>> packages with systemd deps!
> Oh, you wouldn't want to do that. Contrary to what I wrote in
> another thread about "the perfect is the enemy of the good", if *I*
> were in charge of decontamination, I'd throw out whole subsystems.
> Gnome gone. KDE gone. Xfce gone. Networkmanager gone. Gimp gone if
> it gets all systemd on us.
>
> In the massive time I save as not being the bomb squad defusing Red
> Hat's terrorism, I'd write small replacements for a lot of things
> that use only Linux and a very rudimentary and optional GUI
> interface.
>
> Then I'd write documentation explaining how to use a sharp thinking
> computer, to the proud ignorants of the world, especially those who
> believe their ignorance is a badge of honor proving their age or
> gender.
>
> And the people who prioritize pretty over functional and robust: I'd
> tell them to get a Mac.
>
> You don't want me in that capacity.
>
> And yes, I *am* a hypocrit who takes one position in one thread, and
> then says he'd do the opposite in another. :-)
>
> SteveT
>
>

 Please, Steve, provide us with all you mentionned, as an
alternative to mainstream bloated/infected stuff. Since Devuan is all
about freedom, this is the place where to deliver to the world. As
soon as I can install Devuan on metal, I'll be one of your testers.

 Didier


OK. What should come first?

* Automounter?
* No-dbus replacement for NetworkManager/Wicd?
* Other?

Please keep in mind, I'm not a good enough programmer to write a
substitute for Gimp or Gnome. Let's keep the first one simple and easy
so I can actually do it, in a reasonable timeframe, without adversely
impacting my real work.

Thanks,

SteveT

Steve Litt
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust
___
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] Wireless configuration tools (was: Re: Systemd Shims)

2015-08-16 Thread shraptor



Long story short: it's limited, somewhat odd in interface, and nearly
undocumented.
But if you've configured wpa_supplicant to start, or need to write an
initial config file, it should be adequate if you can follow the UI.
I tried to make the UI as obvious as possible, but I'm the only user
I'm aware of, so no promises ;-).



What do you mean by limited? limited by scarce documentation?
limited in user-friendliness?

Well I am thinking of trying it.

It depends on udhcpcd and ifup/ifdown
Are these provided by busybox?


Are there other dependencies except wpa-supplicant, wpa-cli


Does it require something like OpenRC or would it work with
busybox init?


/Scooby



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


Re: [DNG] Systemd Shims

2015-08-19 Thread shraptor

How to learn C if you don't try it?

You have to code in it to learn the lessons.
Just reading a book about it isn't the same.


On 2015-08-19 20:09, Edward Bartolo wrote:

Effectively, you are telling me don't play Russian Roulette with C.
But I like powerful languages that leave the coder in the wilderness
without any hand holding, and C is definitely like that. That is why I
am motivated to use it. The power inherent in C is due to it not
getting in the way of the coder, and I like that.



On 19/08/2015, Rainer Weikusat  wrote:

Rainer Weikusat  writes:


Edward Bartolo  writes:

I am not assuming anything and understand the risks of buffer
overflows. The first step I am taking is to make the code function.
The second step is further debug it until it behaves properly and 
the

third step is to correct any potential security issues.


Realistically, the first step is 'make the code function', the second
step is 'graduate from university based on your thesis' and the 3rd 
was

called 'heartbleed', IOW, that's not going to happen in this way. If
you're doing string processing in C, try to do it correctly from the
start. That's much easier than retrofitting proper length/ size 
handling

onto
some working code.


Example program showing a safe/ secure (and somewhat simplified)
saveFile:


#include 
#include 
#include 

#define IFACE_TMPL \
"auto lo\n" \
"iface lo inet loopback\n\n" \
"iface wlan0 inet dhcp\n" \
"wpa-ssid %s\n" \
"wpa-psk \"%s\"\n"

#define IFACES_PATH "/tmp"

static void saveFile(char* essid, char* pw) //argv[1], argv[2]
{
char *path;
FILE *fp;
unsigned p_len, e_len;

p_len = strlen(IFACES_PATH);
e_len = strlen(essid);
path = alloca(p_len + e_len + 2);

strcpy(path, IFACES_PATH);
path[p_len] = '/';
strcpy(path + p_len + 1, essid);

fp = fopen(path, "ab+");
fprintf(fp, IFACE_TMPL, essid, pw);
fclose(fp);
}

int main(int argc, char **argv)
{
saveFile(argv[1], argv[2]);
return 0;
}
___
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] The show goes on: “su” command replacement merged into systemd on Fedora Rawhide

2015-09-01 Thread shraptor

On 2015-09-01 11:48, Laurent Bercot wrote:

On 01/09/2015 10:29, Jaromil wrote:

if you can confirm the plan of releasing r6-rc within september


 I confirm it.


I am interested in r6-rc is there any place to read more about it
or perhaps I have to wait for the release?


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


[DNG] xf86-input-evdev

2015-09-05 Thread shraptor
On arch linux xf86-input-evdev is reported to have a dependency on 
systemd.


I thought the dependency is on udev and that is usually reported on arch 
like

systemd(udev).

I downloaded xf86-input-evdev for recompilation but could not find any 
switches
to compile without systemd though some evidence pointing at a udev 
dependency was there.



Does anyone know?


best regards

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


Re: [DNG] xf86-input-evdev

2015-09-05 Thread shraptor
Just to be clear my system before upgrade was using vdev in conjunction 
with
xf86-input-evdev and working fine. I did not recompile that version of 
evdev and it

just worked with libudev-compat.

When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static 
conf in xorg.conf.d).


I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.


@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.


Isaac I know about your package and have checked it out before
but didn't fully understand it.

What is triggering evdev in your case? a file in xorg.conf.d?

I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.

I love that you give full explanation, thanks

best regards


Scooby





On 2015-09-05 20:36, Isaac Dunham wrote:

On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
On arch linux xf86-input-evdev is reported to have a dependency on 
systemd.


I thought the dependency is on udev and that is usually reported on 
arch

like
systemd(udev).

I downloaded xf86-input-evdev for recompilation but could not find any
switches
to compile without systemd though some evidence pointing at a udev
dependency was there.

Does anyone know?


Long explanation here.

xf86-input-evdev, as shipped by upstream, is intended to be loaded by 
Xorg's
hotplug support, which depends on libudev (or an API-compatible 
replacement
such as libudev-compat or libeudev...); at least in theory, you can 
also

use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.

So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a 
device

path instead of anything pointing into sysfs.

This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the
corresponding link in /sys/dev/ - this would be the string returned by:
sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.

However, most people prefer to avoid depending on the sysfs layout even
where its behavior is documented; libudev provides a thin veneer to 
hide

it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to 
do

this.
There is no dependency on udev being running.

I've redone that function without udev but using my own library 
libsysdev,

which I mentioned earlier this summer.
Repositories that you'd need to build that:

-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)

But that does require something that has no Debian packaging yet.

There are also two other options:
- comment out that function and disable device hotplug in Xorg.conf or
xorg.conf.d
- replace the function with one that does all the work itself.

HTH,
Isaac Dunham

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


Re: [DNG] xf86-input-evdev

2015-09-05 Thread shraptor

I also forgot to say that on my upgraded system with vdev and
arch version of xf86-input-evdev touchpad gets detected and loaded that 
I believe is

fascilitated by evdev and libudev-compat??

best regards


Scooby


On 2015-09-05 21:40, shraptor wrote:
Just to be clear my system before upgrade was using vdev in conjunction 
with

xf86-input-evdev and working fine. I did not recompile that version of
evdev and it
just worked with libudev-compat.

When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static
conf in xorg.conf.d).

I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.


@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.


Isaac I know about your package and have checked it out before
but didn't fully understand it.

What is triggering evdev in your case? a file in xorg.conf.d?

I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.

I love that you give full explanation, thanks

best regards


Scooby





On 2015-09-05 20:36, Isaac Dunham wrote:

On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
On arch linux xf86-input-evdev is reported to have a dependency on 
systemd.


I thought the dependency is on udev and that is usually reported on 
arch

like
systemd(udev).

I downloaded xf86-input-evdev for recompilation but could not find 
any

switches
to compile without systemd though some evidence pointing at a udev
dependency was there.

Does anyone know?


Long explanation here.

xf86-input-evdev, as shipped by upstream, is intended to be loaded by 
Xorg's
hotplug support, which depends on libudev (or an API-compatible 
replacement
such as libudev-compat or libeudev...); at least in theory, you can 
also

use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.

So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a 
device

path instead of anything pointing into sysfs.

This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the
corresponding link in /sys/dev/ - this would be the string returned 
by:

sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.

However, most people prefer to avoid depending on the sysfs layout 
even
where its behavior is documented; libudev provides a thin veneer to 
hide

it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to 
do

this.
There is no dependency on udev being running.

I've redone that function without udev but using my own library 
libsysdev,

which I mentioned earlier this summer.
Repositories that you'd need to build that:

-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)

But that does require something that has no Debian packaging yet.

There are also two other options:
- comment out that function and disable device hotplug in Xorg.conf or
xorg.conf.d
- replace the function with one that does all the work itself.

HTH,
Isaac Dunham

___
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] xf86-input-evdev

2015-09-05 Thread shraptor

When I read jude's documentation it states

"It also ships with a "libudev-compat" library that is ABI-compatible 
with libudev 219."


My system is libudev 224, does this mean it isn't ABI-compatible 
anymore?


if so how to handle?

On 2015-09-05 21:49, shraptor wrote:

I also forgot to say that on my upgraded system with vdev and
arch version of xf86-input-evdev touchpad gets detected and loaded
that I believe is
fascilitated by evdev and libudev-compat??

best regards


Scooby


On 2015-09-05 21:40, shraptor wrote:
Just to be clear my system before upgrade was using vdev in 
conjunction with

xf86-input-evdev and working fine. I did not recompile that version of
evdev and it
just worked with libudev-compat.

When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static
conf in xorg.conf.d).

I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.


@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.


Isaac I know about your package and have checked it out before
but didn't fully understand it.

What is triggering evdev in your case? a file in xorg.conf.d?

I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.

I love that you give full explanation, thanks

best regards


Scooby





On 2015-09-05 20:36, Isaac Dunham wrote:

On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
On arch linux xf86-input-evdev is reported to have a dependency on 
systemd.


I thought the dependency is on udev and that is usually reported on 
arch

like
systemd(udev).

I downloaded xf86-input-evdev for recompilation but could not find 
any

switches
to compile without systemd though some evidence pointing at a udev
dependency was there.

Does anyone know?


Long explanation here.

xf86-input-evdev, as shipped by upstream, is intended to be loaded by 
Xorg's
hotplug support, which depends on libudev (or an API-compatible 
replacement
such as libudev-compat or libeudev...); at least in theory, you can 
also

use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.

So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a 
device

path instead of anything pointing into sysfs.

This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the
corresponding link in /sys/dev/ - this would be the string returned 
by:

sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.

However, most people prefer to avoid depending on the sysfs layout 
even
where its behavior is documented; libudev provides a thin veneer to 
hide

it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev to 
do

this.
There is no dependency on udev being running.

I've redone that function without udev but using my own library 
libsysdev,

which I mentioned earlier this summer.
Repositories that you'd need to build that:

-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)

But that does require something that has no Debian packaging yet.

There are also two other options:
- comment out that function and disable device hotplug in Xorg.conf 
or

xorg.conf.d
- replace the function with one that does all the work itself.

HTH,
Isaac Dunham

___
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] xf86-input-evdev

2015-09-05 Thread shraptor

Problem solved

when I changed so names from


libudev.so
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4 -> libudev.so


to

libudev.so
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.5.2
libudev.so.1.5.2 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4 -> libudev.so


though for original libudev from arch has

libudev.so -> libudev.so.1.6.4
libudev.so.1 -> libudev.so.1.6.4
libudev.so.1.6.4

and that doesn't work for me

Anyone can clear up naming conventions of so-names?

Maybe correct should be


libudev.so -> libudev.so.1
libudev.so.1 -> libudev.so.1.0.1
libudev.so.1.0.1 -> libudev.so.1.5.1
libudev.so.1.5.1 -> libudev.so.1.5.2
libudev.so.1.5.2 -> libudev.so.1.6.0
libudev.so.1.6.0 -> libudev.so.1.6.4
libudev.so.1.6.4


will try if that works now

best regards


Scooby





On 2015-09-05 22:57, shraptor wrote:

When I read jude's documentation it states

"It also ships with a "libudev-compat" library that is ABI-compatible
with libudev 219."

My system is libudev 224, does this mean it isn't ABI-compatible 
anymore?


if so how to handle?

On 2015-09-05 21:49, shraptor wrote:

I also forgot to say that on my upgraded system with vdev and
arch version of xf86-input-evdev touchpad gets detected and loaded
that I believe is
fascilitated by evdev and libudev-compat??

best regards


Scooby


On 2015-09-05 21:40, shraptor wrote:
Just to be clear my system before upgrade was using vdev in 
conjunction with
xf86-input-evdev and working fine. I did not recompile that version 
of

evdev and it
just worked with libudev-compat.

When I upgraded to new version of both( and new kernel)
keyboard stopped working( though could be brought to life with static
conf in xorg.conf.d).

I thought maybe arch had done something to break functionality
here. It could also be some regression in vdev and I will speak
to jude about that after September 12 when he's got more time.


@Jack Frost
I do not understand the use of .pc files although I have seen them
around. I am using your systemd-dummy package though to avoid pulling
in real systemd, Thanks for that.


Isaac I know about your package and have checked it out before
but didn't fully understand it.

What is triggering evdev in your case? a file in xorg.conf.d?

I am gonna try your solution with libsysdev and sysdev branch
of xf86-input-evdev. Although it would easier( for me that is) if
the arch version just worked with vdev.

I love that you give full explanation, thanks

best regards


Scooby





On 2015-09-05 20:36, Isaac Dunham wrote:

On Sat, Sep 05, 2015 at 01:49:14PM +0200, shraptor wrote:
On arch linux xf86-input-evdev is reported to have a dependency on 
systemd.


I thought the dependency is on udev and that is usually reported on 
arch

like
systemd(udev).

I downloaded xf86-input-evdev for recompilation but could not find 
any

switches
to compile without systemd though some evidence pointing at a udev
dependency was there.

Does anyone know?


Long explanation here.

xf86-input-evdev, as shipped by upstream, is intended to be loaded 
by Xorg's
hotplug support, which depends on libudev (or an API-compatible 
replacement
such as libudev-compat or libeudev...); at least in theory, you can 
also

use it as a pre-configured device driver.
The hotplug path will load evdev for *all* input devices that are
hotplugged--power buttons included.

So, evdev needs to check if a device is "virtual".
This is a simple matter of checking that the canonical path in sysfs
contains the string "LNXSYSTM".
Getting that canonical path is the hard part, since you receive a 
device

path instead of anything pointing into sysfs.

This can be done more-or-less by getting the device major and minor
via stat(), checking that it's a char device, then identifying the
corresponding link in /sys/dev/ - this would be the string returned 
by:

sprintf(buf, "/sys/dev/char/%hu:%hu", major, minor)
and then use readlink() to check where it points; the result is the
canonical path.

However, most people prefer to avoid depending on the sysfs layout 
even
where its behavior is documented; libudev provides a thin veneer to 
hide

it.
So in src/evdev.c, function EvdevDeviceIsVirtual, they use libudev 
to do

this.
There is no dependency on udev being running.

I've redone that function without udev but using my own library 
libsysdev,

which I mentioned earlier this summer.
Repositories that you'd need to build that:

-https://github.com/idunham/libsysdev
-https://github.com/idunham/xf86-input-evdev (branch sysdev)

But that does require something that has no Debian packaging yet.

There are also two other options:
- comment out 

[DNG] Xorg dependency on libsystemd

2015-09-13 Thread shraptor

When I check on Arch linux the only dependency they explicitly
states is xorg-server-xnest is dependent on libsystemd.
I do not have this package installed.

When I try to run my os Xorg complains about missing libsystemd

There is some package builds in AUR and if I check them
I see  --enable-systemd-logind  under ./configure command

So I guess that its this where th dependency comes from.

So if I recompile without it maybe I can run without libsystemd
installed?

Anyone have any experience regarding this?

Is it hard to compile and get Xorg to work?

Any comments would be most welcome
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Xorg dependency on libsystemd

2015-09-13 Thread shraptor

On 2015-09-13 16:31, ibid...@gmail.com wrote:

On Sun, Sep 13, 2015 at 03:51:16PM +0200, shraptor wrote:

When I check on Arch linux the only dependency they explicitly
states is xorg-server-xnest is dependent on libsystemd.
I do not have this package installed.

When I try to run my os Xorg complains about missing libsystemd

There is some package builds in AUR and if I check them
I see  --enable-systemd-logind  under ./configure command

So I guess that its this where th dependency comes from.

So if I recompile without it maybe I can run without libsystemd
installed?

Anyone have any experience regarding this?

Is it hard to compile and get Xorg to work?


systemd-logind integration is via dbus; configure X without dbus
or at least without systemd-logind.

If you're re-compiling a package, it usually is pretty easy to
get X working.

HTH,
Isaac Dunham


I need to somehow figure out which package needs libsystemd

I have a dbus package cleaned of systemd

Made a quick test of recompiling xorg-server-* packages but
configure complained of no udev.

I have no udev but vdev

Maybe have to fool this check somehow






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


Re: [DNG] Xorg dependency on libsystemd

2015-09-14 Thread shraptor

On 2015-09-13 23:44, k...@aspodata.se wrote:

Shraptor:

When I check on Arch linux the only dependency they explicitly
states is xorg-server-xnest is dependent on libsystemd.
I do not have this package installed.

When I try to run my os Xorg complains about missing libsystemd

There is some package builds in AUR and if I check them
I see  --enable-systemd-logind  under ./configure command

So I guess that its this where th dependency comes from.

So if I recompile without it maybe I can run without libsystemd
installed?

Anyone have any experience regarding this?

Is it hard to compile and get Xorg to work?

Any comments would be most welcome


I got xorg to work on a funtoo box and that without any udev nor
libudev. I.e. there is no dependancy.

Regards,
/Karl Hammar



Was there libsystemd on your funtoo setup?

The dependency I found was on systemd-login.
The udev dependency probably is just arch buildscripts.

If I include libsystemd my system starts fine
with vdev

Did you recompile Xorg. which parts?


I saw some mention you may have to
recompile xf86-input-evdev also
if you recompile xorg-server


How did you do it?

best regards

Scooby

---

Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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] Xorg dependency on libsystemd

2015-09-17 Thread shraptor

Now got xorg-server recompiled without systemd dependencies

Used suggestion of adding eudev .pc file to vdev

Feels good to run your system with no systemd/libsystemd :)




On 2015-09-14 14:26, k...@aspodata.se wrote:

shraptor:

On 2015-09-13 23:44, k...@aspodata.se wrote:

...

> I got xorg to work on a funtoo box and that without any udev nor
> libudev. I.e. there is no dependancy.

...

Was there libsystemd on your funtoo setup?


No, none.


The dependency I found was on systemd-login.
The udev dependency probably is just arch buildscripts.


Yes, seems to be in many distribution buildscripts.
Seems maintainers by reflex think udev is installed, that they
want it themselfs, or that it provides some convenience that shouldn't
be left out.


If I include libsystemd my system starts fine
with vdev

Did you recompile Xorg. which parts?


Since it's funtoo (which is based on gentoo): everything.


I saw some mention you may have to
recompile xf86-input-evdev also
if you recompile xorg-server

How did you do it?


By modifying the funtoo build script, removing mentions of udev:

$ cd /usr/portage
$ diff ./x11-drivers/xf86-input-evdev/xf86-input-evdev-2.9.2.ebuild*
10c10
< RDEPEND=">=x11-base/xorg-server-1.12
---

RDEPEND=">=x11-base/xorg-server-1.12[udev]

$ diff x11-base/xorg-server/old/xorg-server-1.16.4-r1.ebuild
x11-base/xorg-server/xorg-server-1.16.4-r1.ebuild
12c12
< IUSE="dmx kdrive xnest +xorg xvfb glamor ipv6 minimal nptl selinux
+suid systemd tslib +udev unwind wayland"
---
IUSE="dmx kdrive xnest +xorg xvfb glamor ipv6 minimal nptl selinux 
+suid systemd tslib unwind wayland"

60d59
<   udev? ( >=virtual/udev-150 )
170d168
<   $(use_enable udev config-udev)
$

  and then

# emerge --regen

I don't remeber if I had to do anything with mesa. In mesa there is:

$ git remote -v
origin  git://anongit.freedesktop.org/git/mesa/mesa (fetch)
origin  git://anongit.freedesktop.org/git/mesa/mesa (push)
$ ./configure --help | grep sysfs
  --enable-sysfs  enable /sys PCI identification 
[default=disabled]

$

which you can use instead of libudev.

///

If you run current xorg server, you have to make your own xorg.conf (I
think). I added flag below to make it work:

Section "ServerFlags"
...
Option "AutoAddDevices" "off"
EndSection

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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 update: eventfs

2015-09-22 Thread shraptor

So how to get eventfs going with vdev.

./eventfs /run/udev

or where should eventfs be mounted?


Eventfs mounting will not be handled by vdev, right?


/scooby


On 2015-09-22 04:44, Jude Nelson wrote:

Hey everyone,

I promise, I'm not dead :)  I've been working on vdev off and on over
the past couple months as time permitted, but I haven't had anything
interesting to report here (mostly bug fixes, which are tracked on the
project's Github [1]).  This past week I've been able to spend more
time on vdev, now that my major event for $WORK has come and gone.

I'm pleased to announce the availability of eventfs [2], the final
piece of software required to replace udev.  Eventfs is a specialized
userspace filesystem that replaces the udev-to-libudev event multicast
protocol, which is currently based on netlink but will soon be based
on kdbus.  Eventfs fulfills an equivalent role, but it does so in a
portable manner in userspace, and it abstracts dealing with message
multicast groups as dealing with files and directories with a few
extra rules [3].

I'm going to migrate my production machine to using eventfs with
libudev-compat this weekend.  Once I'm satisfied that it works as
expected, I'll begin packaging all of vdev's components for Devuan.

Questions, comments, and feedback are all welcome :)

Thanks,y
Jude

[1] https://github.com/jcnelson/vdev [1]
[2] https://github.com/jcnelson/eventfs [2]
[3] https://github.com/jcnelson/eventfs/blob/master/README.md [3]

Links:
--
[1] https://github.com/jcnelson/vdev
[2] https://github.com/jcnelson/eventfs
[3] https://github.com/jcnelson/eventfs/blob/master/README.md

___
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 update: eventfs

2015-09-23 Thread shraptor

On 2015-09-23 17:14, Jude Nelson wrote:

@shraptor

 So how to get eventfs going with vdev.
./eventfs /run/udev
or where should eventfs be mounted?
Eventfs mounting will not be handled by vdev, right?


Vdev won't set up eventfs.  I'll ship a sysv init script with it that
will mount it automatically (probably shortly after init starts, since
libudev-compat programs will need it relatively early in the boot
process).


Is it a hard dependency on eventfs?

Or will some functionality work without eventfs?

Is it the same data as was made availible in /run/udev before??




I was planning on having it mounted on /run/events, in order to make
it available as a generic IPC system for other programs to use for
their own purposes.  Eventfs isn't specific to vdev; I'm hoping to
use it as a partial alternative to dbus.  I'm open to alternative
mount points, though.

@jaromil

 Amazing news. noone here doubts you are continuing to build up on

the

solid foundations you laid, I am sure vdev will become a relevant
component for many mission-critical GNU/Linux system installations.



Please do not hesitate to ask for anything you need in terms of
infrastructure and funding we can contribute from our donation pot.


Thank you for your generous offer!  I think I'm fine for now insofar
as development infrastructure, but one thing that will be particularly
tricky is creating the packaging scripts needed to replace udev
automatically, but without rendering the host unbootable if something
goes wrong.

Thanks,
Jude

On Tue, Sep 22, 2015 at 6:20 AM, vmlinux  wrote:


Great news! Thank you for all your efforts!

On September 21, 2015 9:44:12 PM CDT, Jude Nelson
 wrote:

::I'm pleased to announce the availability of eventfs

--
Sent from a Mobile device.



___
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] libinput

2015-10-21 Thread shraptor

I am having trouble with vdev and evdev on an Arch linux derivative.
The problem is only with USB devices. Mem sticks work but having trouble 
with

mouse. /dev/input seems OK so it is some libudev/evdev issue perhaps?

I thought of trying libinput instead to see if that works.

My question is if libinput is part of the red hat strive for domination
of the linux market?

And if so it may be better to stay clear of it?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] Is Jude Nelson OK?

2015-10-26 Thread shraptor

Did something happen to Jude.

I have worked with him on vdev for half a year
and he usually replies pretty fast.

Maybe he is just swamped with work.

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


Re: [DNG] Packaging vdev

2015-11-08 Thread shraptor

On 2015-11-07 22:09, aitor_czr wrote:

Hi all,

I just started with fskip:

http://gnuinos.org/vdev/

It builds successfully, but after a installation i saw the following
issue: all the /usr/lib/*.o files are missing !!


Did you call make in vdev/libudev-compat also?

i.e

cd /path/to/vdev/libudev-compat
make
make install

??






Cheers,

   Aitor.

___
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] Packaging vdev

2015-11-08 Thread shraptor

On 2015-11-08 14:24, shraptor wrote:

On 2015-11-07 22:09, aitor_czr wrote:

Hi all,

I just started with fskip:

http://gnuinos.org/vdev/

It builds successfully, but after a installation i saw the following
issue: all the /usr/lib/*.o files are missing !!


Did you call make in vdev/libudev-compat also?

i.e

cd /path/to/vdev/libudev-compat
make
make install

??


Sorry read a little bit fast there, thought you was building vdev but
you are working on fskit


anyway default is /usr/local/lib/*
Defaults can be overridden in buildconf.mk










Cheers,

   Aitor.

___
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] Extended partition

2015-11-15 Thread shraptor

Does vdev handle extended partitions properly?

Have anyone tried?

Does extended partitions require lvm2 package on linux?

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


Re: [DNG] XFCE terminal alternatives?

2015-12-07 Thread shraptor

You could have a look at AltYo

https://github.com/linvinus/AltYo

I always compiled from  git but there is evidence of debian
packaging in repo so should be easy to install on devuan?

best regards

Scooby


On 2015-12-07 17:26, Steve Litt wrote:

On Mon, 7 Dec 2015 09:39:18 -0600
dev  wrote:


I've been using Devuan on my desktop for a number of months now. Very
nice! Only thing is about once a week the XFCE Terminal (in drop down
mode) will sort of crash when closing GTK applications.


[snip]


I like the tabs and the drop-down feature of XFCE Terminal as well as
the light footprint. I've tried others[1] such as Terra Terminal,
Terminator and Yakuake but can't seem to find one with all the right
features. Any suggestions?  ...installing Guake atm..


Guake is good for stuff that it's good for.

I've always found Xfce a little bit glitchy. You might want to try
installing and running LXDE, with it's lxterminal as an almost
identical substitute to xfce4-terminal. Not only that, but it's just
possible that xfce4-terminal will behave better in an LXDE environment
than it did in an Xfce environment. I put LXDE on all my laptops,
because if my computer simply must work, and I need a panel, then LXDE
is what I want.

You could also try Openbox plus Dmenu. And I highly recommend using
Dmenu with LXDE: It's easy.

By the way, all the preceding is a guess. And everything I suggested is
easily reversible. It's easy to flip between LXDE and Xfce.

HTH,

SteveT

Steve Litt
November 2015 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
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] top posting, was: Re: Debianising my uploaded version of netman.

2015-12-12 Thread shraptor
I must admit I am really clueless to what is considered good practice in 
mailing-lists.
I started coding on abc-80 but I only really know bulletin board style 
interaction(same as git, right?) or personal email.

Not everybody was there at the start.

I am lost in mailing-lists but feel like I have something to enrich 
devuan namespace anyway.


As a user with roots in Window$ I feel an emotional distrust of local 
running email clients.

Using webmail with little thread or mailing-list support right now.

I am not rude on purpose but I truly don't know mailing-list style of 
interaction.

Should I delete this or keep this? Write here or write there?
It's like it's only for those initiated in the secret art?
Better to just top-post then, ehhh???
Better to keep my input to minimum as to not enrage the old authorative 
giants, huh!?



Is there no compiler for mailing-list emails?
maybe there should be?

best regards

Scooby





On 2015-12-12 20:46, Rainer Weikusat wrote:

Jaromil  writes:

On Fri, 11 Dec 2015, Gregory Nowak wrote:
I have to throw in my $0.01 here. First, like Edward, I too prefer 
top

posting. I have noticed also that top posting seems to be an
overwhelming convention on blindness-related lists. I have seen
instances of bottom posters getting flamed on a blindness-related 
list

for doing so.


this sounds strange. since its very inception we have struggled to 
keep
Dyne.org infrastructure and practices as friendly as possible for 
people

with low or even no vision, since some of our funding members had such
conditions. In my experience bottom posting is fine, as screen readers
should be recognizing and signaling the quote prefix '>' and offer to
skip over it.


'Top posting' vs 'bottom posting' is a false dichotomy (could also be
regarded as strawman): It's really "unredacted full-quote with some 
text

attached", possibly even "unredacted full-quote of something completely
unrelated" vs "reply to the text you're replying to and keep enough of
the context that readers can understand what you are writing
about". There are also people who put their own text below an 
unredacted

full-quote but that's not really different from putting it at the top:
Both are examples of an "can't be bothered to express myself clearly"
mentality (Reader can figure that out! If not, screw him!).

___
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] top posting, was: Re: Debianising my uploaded version of netman.

2015-12-14 Thread shraptor



caveman, simply bother to *manually* delete the unrelated content
every single time I reply to an email, and to quote only those bits
that I consider necessary to set the context.



I have no problem trying this out.

I believe there it is also a question of what the mind is used to. For 
me it is easier to read top-posted emails

since that is what I am used to. When I started reading this
mailing-list I often missed text further down since I thought
the author was done.

I remember having the same problems when switching from win to linux. 
Also at one time I was so accustomed to google search results. I mean 
the visual representation. I even

greasemonkeyed duckduckgo search-results to look like googles.

For me it's better to train on staying flexible and
have a bit more patience so I will try to not top-post.

btw was this email OK?

I can report it was a bitch to write using my jolla phone.
Just place the cursor is frustrating. also with jolla
text disappears so not that easy on smartphone as on a
regular comp.

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


[DNG] newly developed packages

2015-12-30 Thread shraptor

What about newly developed programs like
https://github.com/albfan/miraclecast

They are developed from start to use systemd.

Miraclecast uses systemd, sd-bus and kdbus(not really, only the 
independent and experimental sd-libraries)
also DHCP but it will be removed once sd-dns gains DHCP-server 
capabilities.


Seems like a lot of hacking to run without systemd?

I'd really like to use that one.

Do you think it can be cleaned?


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


Re: [DNG] Predictable Network Interface Names - Stupid or good idea?

2016-01-09 Thread shraptor

On 2016-01-09 19:17, Anto wrote:


On the topic. It would be quite interesting how vdev will be (or is)
managing this network interface naming assignment. Do you have any
comment on this, Jude?


vdev uses by default old naming convention but has a file
called /etc/vdev/ifnames.conf where you can set names arbitrarily.

Example ifnames.conf that is auto-generated at compile time
(only covered up my mac addresses)

# Format:
# PERSISTENT_INTERFACE_NAME mac|devpath MATCH_ARGUMENT
#   * PERSISTENT_INTERFACE_NAME is the persistent name of the network 
interface
#   * If the second argument is "mac", then MATCH_ARGUMENT is the 
colon-separated MAC address
#   * If the second argument is "devpath", then MATCH_ARGUMENT is the 
device path to the NIC in sysfs

#
# Example: a wireless USB dongle, to be named "wlan-edimax"
#
# Using the "mac" match:
# wlan-edimax mac 80:1F:02:D3:B2:83
#
# Using the "devpath" match:
# wlan-edimax devpath 
/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1/1-1.1:1.0


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


Re: [DNG] Beware

2016-01-19 Thread shraptor

On 2016-01-19 16:58, Steve Litt wrote:

Beware:

http://www.networkworld.com/article/3023447/security/linux-zero-day-affects-most-androids-millions-of-linux-pcs.html


Would this type of misbehavior be mitigated by kernel ASLR?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Beware

2016-01-19 Thread shraptor

On 2016-01-19 19:07, Rainer Weikusat wrote:

In this particular case, an unprivileged local user could gain root
access by running a program which does billions of syscalls as fast as
it can for ca 30 minutes (according the 'real' article).


I tested the program in the 'real' article but it didn't work?

But I guess you have to adjust addresses of commit_creds and 
prepare_kernel_cred functions for my kernel version?
The article says they are static and can be determined per Linux kernel 
version.


How to determine those? some kind of stacksmashing?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] Beware

2016-01-20 Thread shraptor

On 2016-01-19 23:07, Rainer Weikusat wrote:


You can find them in the System.map file for your kernel, eg,

...

Found it in my System.map


810a97d2 T prepare_kernel_cred
810a94b7 T commit_creds


Thanks for hint


some kind of stacksmashing?


No. The bug in the kernel function causes a reference to some object to

...

Thank you for that concise explanation, understanding a bit better now.

Entered the addresses from my kernel and ran the program.

It took 37 min to complete

$ ./cve_2016_0728 PP_KEY
uid=1000, euid=1000
Increfing...
finished increfing
forking...
finished forking
caling revoke...
uid=1000, euid=1000
$ id -u
1000
$ id -un
alpha


I am still not root at the end? Maybe a bit overestimated this bug?

I am on kernel 4.1.6

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


Re: [DNG] Change netman into another name.

2016-02-05 Thread shraptor

On 2016-02-05 18:15, Go Linux wrote:

Every name I came up with was already in multiple use.  I also thought
of netbarx which is completely unique.  Kinda like it actually.

golinux



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


Re: [DNG] Change netman into another name.

2016-02-05 Thread shraptor

On 2016-02-05 21:12, Edward Bartolo wrote:

Hi,

I will NOT name the project after myself; I even abstained from
voting. My project was written to HELP; I am not after
self-appraisal...


That's too bad cause I honestly think netbarx is a real good name.
I urge you to reconsider, at least let it be included in vote.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] transmission-daemon package

2016-02-06 Thread shraptor

On 2016-02-06 17:18, dev1fanboy wrote:

So I am trying to build transmission-daemon without systemd, was just
testing this locally and run into an issue. It can be built without
systemd but transmission-gtk will no longer start downloading
torrents.

I think it is down to this error which appears when running
transmission-gtk in a terminal:

** (transmission-gtk:32682): WARNING **: Error retrieving
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown:
The name
org.a11y.Bus was not provided by any .service files


I am on Arch derivative and I can tell for certain that transmission-gtk
works without systemd or libsystemd

I am using the original package for transmission-gtk on Arch Linux
However I have dbus compiled without systemd that is not default on 
Arch.


I think you should rather look on dbus than transmission.

Hope this helps even if we're not exactly on the same dist

Best regards

Scoob



Can anyone suggest a way to solve this, or provide a patch? If so I'll
try to get it working for jessie and put it on the gitlab.

Cheers,

chillfan

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


Re: [DNG] transmission-daemon package

2016-02-07 Thread shraptor

On 2016-02-07 03:26, shraptor wrote:

On 2016-02-06 17:18, dev1fanboy wrote:

So I am trying to build transmission-daemon without systemd, was just
testing this locally and run into an issue. It can be built without
systemd but transmission-gtk will no longer start downloading
torrents.

I think it is down to this error which appears when running
transmission-gtk in a terminal:

** (transmission-gtk:32682): WARNING **: Error retrieving
accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown:
The name
org.a11y.Bus was not provided by any .service files


I downloaded source and built transmission without systemd.

Started transmission-daemon and successfully downloaded a torrent
using transmission-remote.

If I then start transmission-gtk I get the same behavior as you.
The torrent doesn't start. I get no dbus error in terminal though.

If I kill transmission-daemon and restart transmission-gtk the torrent 
starts.


I am not sure what setup you're after but transmission-gtk works without
transmission-daemon!?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] transmission-daemon package

2016-02-07 Thread shraptor

Turns out both can work on debian jessie, so can't fix this unless
there is a patch somewhere.


Do you mean both transmission-gtk and transmission-daemon ?

I tested some more and if you define another port than default
then you can run transmission-gtk and transmission-daemon
at the same time.

If it's that, this could be said to be fixed by changing
default port to something else, perhaps this can be done
in config-files?


Or did I get you wrong? What do you want to patch?


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


Re: [DNG] transmission-daemon package

2016-02-07 Thread shraptor

On 2016-02-07 20:38, dev1fanboy wrote:

Ah I didn't think to check that, it does work here when changing the
port. Maybe this behaviour is okay, e.g someone would normally use
only one at a time, or otherwise change the port. Anyone have any
thoughts on that?

If it doesn't seem like the right behaviour I could try to change the
default ports somehow.


I think its fine as it is. Its enough to remove dependency on libsystemd
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] state of what's working for modern desktop usage

2016-02-09 Thread shraptor



I noticed too that no vdev were installed, expected?


Vdev is still in its final stages of development, as far as I know.
Running on developpment asd some test systems, but still being
thorougly tested on corner cases before being introduced into Devuan.

-- hendrik


It is my belief that vdev should go in some testing or development repo. 
I am running out of errors to report

and fix with Jude's help on my hardware and my very
small userbase for alphaOS.

It's a bit like arnt said in another thread: if everybody
is waiting nothing happens.

Maybe there is still issues regarding vdev and initramfs for
devuan?

Anyway I think vdev could use a bit more users for it to
mature.

best regards

Scooby

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


Re: [DNG] state of what's working for modern desktop usage

2016-02-09 Thread shraptor

On 2016-02-09 15:20, Hendrik Boom wrote:

On Tue, Feb 09, 2016 at 09:15:28AM +0100, shraptor wrote:


>>I noticed too that no vdev were installed, expected?
>
>Vdev is still in its final stages of development, as far as I know.
>Running on developpment asd some test systems, but still being
>thorougly tested on corner cases before being introduced into Devuan.
>
>-- hendrik

It is my belief that vdev should go in some testing or development
repo.


Like Debian's 'experimental' repo?


Yes, something not official but so people on this list could test out.

I am on Arch linux derivative and am not familiar with deb-files.
Alas I am lost on the initramfs front too since I use busybox->mdev in 
initramfs


I am running vdev with good results though.

I know obarun had problem running vdev in initramfs on his 
Arch-systemd-free distro.


Is it possible in devuan to run eudev in initramfs and vdev when booted?
As a means to get it to testing more quickly.

vdev seems to be stuck in a "which came first, the chicken or the 
egg?"-dilemma


It deserves better.


/scooby



-- hendrik
___
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] vdev packaging effort ( was: state of what's working for modern desktop usage)

2016-02-10 Thread shraptor

On 2016-02-10 00:35, Adam Borowski wrote:

On Tue, Feb 09, 2016 at 09:20:32AM -0500, Hendrik Boom wrote:

On Tue, Feb 09, 2016 at 09:15:28AM +0100, shraptor wrote:
> >Vdev is still in its final stages of development, as far as I know.
> >Running on developpment asd some test systems, but still being
> >thorougly tested on corner cases before being introduced into Devuan.
>
> It is my belief that vdev should go in some testing or development
> repo.

Like Debian's 'experimental' repo?


Yes please!

If you think the code is in good enough shape to be unleashed into the
public, even into experimental, I'd be delighted to help on the
packaging/uploading front.

(I know nothing about the workings of udev, though.)


I think the code is good enough and now is the time to get more users 
testing it.

It works on my specific hardware cause I bug-hunted the sh** out of it.
needs to be tested on more computers.

I guess I have to install devuan to get a working environment then.
Any input on what would be a good install iso for this? I mean
an iso with a system we should target. Maybe better to do a virtualbox
install, might be a lot of rebooting with initramfs work.

Thank you Adam for offering help, Are you knowledgeable on initramfs in 
general?
I think we need someone versed in debian/devuan initramfs generation 
with hooks and so

on?


I think Aitor wrote a while ago about creating a vdev package?
Aitor could you give an update on that effort?


best regards

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


Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

2016-02-10 Thread shraptor

On 2016-02-10 15:09, Jaromil wrote:

On Wed, 10 Feb 2016, shraptor wrote:



Thank you Adam for offering help, Are you knowledgeable on initramfs
in general?  I think we need someone versed in debian/devuan
initramfs generation with hooks and so on?


on irc #devuan there is gdm85 who is an expert on this. He is also in
Amsterdam and will join us in person for a Devuan beta sprint we are
planning on Friday at Dyne.org HQ

If you can be around on the channel on friday evening and/or lineup
some questions on problems you encounter then we can put this as a
TODO item and work following his lead on the initramfs issues.



I am sorry but that's much to soon. Like everybody else here
time is scarce for me. No way I get setup till friday, Don't even think 
I got

time on friday to put aside.



An installable package of vdev in Devuan beta will definitely leverage
its testing base. Thanks for working on this, is quite important.


I agree and think it's important that's why I began thinking about this





ciao

___
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 packaging effort ( was: state of what's working for modern desktop usage)

2016-02-10 Thread shraptor

On 2016-02-10 15:11, Didier Kryn wrote:

Le 10/02/2016 12:02, shraptor a écrit :

On 2016-02-10 00:35, Adam Borowski wrote:

On Tue, Feb 09, 2016 at 09:20:32AM -0500, Hendrik Boom wrote:

On Tue, Feb 09, 2016 at 09:15:28AM +0100, shraptor wrote:
> >Vdev is still in its final stages of development, as far as I know.
> >Running on developpment asd some test systems, but still being
> >thorougly tested on corner cases before being introduced into Devuan.
>
> It is my belief that vdev should go in some testing or development
> repo.

Like Debian's 'experimental' repo?


Yes please!

If you think the code is in good enough shape to be unleashed into 
the

public, even into experimental, I'd be delighted to help on the
packaging/uploading front.

(I know nothing about the workings of udev, though.)


I think the code is good enough and now is the time to get more users 
testing it.
It works on my specific hardware cause I bug-hunted the sh** out of 
it.

needs to be tested on more computers.

I guess I have to install devuan to get a working environment then.
Any input on what would be a good install iso for this? I mean
an iso with a system we should target. Maybe better to do a virtualbox
install, might be a lot of rebooting with initramfs work.

Thank you Adam for offering help, Are you knowledgeable on initramfs 
in general?
I think we need someone versed in debian/devuan initramfs generation 
with hooks and so

on?


I think Aitor wrote a while ago about creating a vdev package?
Aitor could you give an update on that effort?


best regards

Scooby


I have some experience with initramfs, and I have already tested
vdev with Busybox in initramfs a while ago. But have no experience in
generating a Debian/Devuan initramfs. Here's my experience with
vdev+busybox:

There was two problems:
1) Busybox's blkid doesn't accept any option. Formatting options
are no problem because vdev manages to not use them, but the -p option
is definitely missing. To be able to fully test vdev, I had to build
the legacy blkid from util-linux.
2) At the time of this test campaign, the shebang line of vdev
scripts was #!/bin/dash, which doesn't work in Busybox. It should be
replaced by #!/bin/sh which works in all cases.


Scripts are still dash



With the conditions described above, ie busybox, vdev, blkid (all
linked statically against Musl libc) and modified shebang lines, the
startup was working without error when booting from a USB key on my
amd64 laptop.

I guess in Devuan/Debian, Busybox is dynamicaly linked against
glibc; therefore adding blkid wouldn't dramatically increase the
bloat.



Thanks a lot for information, Any is valuable.

I am not familiar with debian/devuan at all, I come from the Arch Linux 
way
of doing things. It will take some time to get down with devuan I am 
sure.


There is probably a world of difference between arch and debian/devuan.



Didier

___
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 packaging effort ( was: state of what's working for modern desktop usage)

2016-02-11 Thread shraptor

On 2016-02-11 10:56, Didier Kryn wrote:

Le 10/02/2016 23:37, Rainer Weikusat a écrit :

Didier Kryn  writes:

Le 10/02/2016 18:50, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]

  2) At the time of this test campaign, the shebang line of 
vdev
scripts was #!/bin/dash, which doesn't work in Busybox. It should 
be

replaced by #!/bin/sh which works in all cases.

This isn't necessarily true. Both dash and the usual busybox sh are
forks of the Amquist shell (ash) which is supposed to be enable to
execute scripts written in the Bourne shell language/ for the
standardized /bin/sh but they also provide extensions of their own 
(eg,

like bash, dash supports lexically scoped function variables but the
Bourne/ standard shell doesn't). The busybox ash can also compiled 
w/o

certain features, eg, arithmetic expansion.

'Replacing /bin/dash with /bin/sh' will only work if the author of 
the

script use the non-standard name because he doesn't knew any better
instead of because the script actually uses dash features.

 There's no theory behind that. It's just practical and the 
result

of experimenting.

 The way Busybox works is all applications are links to
/bin/busybox. When invoqued, /bin/busybox

... looks at argv[0] and invokes the corresponding embedded
program. "Everybody knows that" (well, not everybody but everybody who
ever worked with busybox) .

 On the other hand, the default shell in Debian, the one invoked 
by

/bin/sh, is dash. I guess in every distro /bin/sh points to the
~POSIX-compliant shell. Therefore '#!/bin/sh' should just work
everywhere.

It should be the name of a shell capable of running Bourne/ standard
shell scripts. But this may not work if the /bin/dash in the original
script was there for a reason, ie, it was using dash features.


As I already wrote, vdev was working well with busybox's ash.,
replacing 'dash' with 'sh' in the shebang.

If the question is why Jude replaced /bin/sh with /bin/dash in the
middle of the development, I think it was to make sure to not invoke
bash.


In my setup /usr/bin/dash is a symlink to /usr/bin/bash

It works!

 I don't think that's why Jude chose dash?



But (sorry for the repetition) I used to modify the shebang
everytime I tested a new version, and there was never any issue with
the shell.

Another possibility would be to write a wrapper script called
/bin/dash, like
#! /bin/sh
exec /bin/sh $@

Didier


___
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 packaging effort ( was: state of what's working for modern desktop usage)

2016-02-12 Thread shraptor

On 2016-02-11 23:48, Didier Kryn wrote:

Le 11/02/2016 19:25, shraptor a écrit :

In my setup /usr/bin/dash is a symlink to /usr/bin/bash


That's a big mistake.

On any Debian system, /bin/sh points to /bin/dash, and dash
doesn't point to bash. Your system has certainly been hacked.


Yes, It has been hacked by me,

I could have installed dash but a symlink worked fine.




It works!

Sure, bash can process ash scripts. The problem is the opposite
isn't true because bash provides a lot of additional features,
"bashisms", which distros decided to erradicate from their scripts.
Users are free to write bash or ksh scripts, but portable scripts must
execute on ash.

Didier

___
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 packaging effort ( was: state of what's working for modern desktop usage)

2016-02-12 Thread shraptor

On 2016-02-12 10:50, Didier Kryn wrote:

Le 12/02/2016 02:54, Rainer Weikusat a écrit :

Didier Kryn  writes:


Le 11/02/2016 17:04, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]

It should be the name of a shell capable of running Bourne/ 
standard
shell scripts. But this may not work if the /bin/dash in the 
original

script was there for a reason, ie, it was using dash features.

  As I already wrote, vdev was working well with busybox's 
ash.,

replacing 'dash' with 'sh' in the shebang.

  If the question is why Jude replaced /bin/sh with /bin/dash 
in the
middle of the development, I think it was to make sure to not 
invoke

bash. But (sorry for the repetition) I used to modify the shebang
everytime I tested a new version, and there was never any issue 
with

the shell.

There is no question here. *If* the script in question uses dash
spuriously, ie, it doesn't use features specific to dash but is 
actually

a Bourne shell script, replacing /bin/dash with /bin/sh should be
fine. If not, stuff is going to break sooner or later, either 
because

/bin/sh isn't really dash (eg, someone might use bash for that) or
because of difference between the busybox and Debian (d)ash forks.


 There shouldn't be any "feature specific to dash", by
construction.
There are, "by construction". Eg, dash supports local, the POSIX 
/bin/sh

doesn't.
Then it seems Jude's scripts don't use that feature, and they 
shouldn't.



If you check *.sh in vdev/vdevd/helpers/LINUX on git they use local





 Didier

___
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 packaging effort ( was: state of what's working for modern desktop usage)

2016-02-12 Thread shraptor

On 2016-02-12 15:34, shraptor wrote:

On 2016-02-12 10:50, Didier Kryn wrote:

Le 12/02/2016 02:54, Rainer Weikusat a écrit :

Didier Kryn  writes:


Le 11/02/2016 17:04, Rainer Weikusat a écrit :

Didier Kryn  writes:

[...]

It should be the name of a shell capable of running Bourne/ 
standard
shell scripts. But this may not work if the /bin/dash in the 
original

script was there for a reason, ie, it was using dash features.

  As I already wrote, vdev was working well with busybox's 
ash.,

replacing 'dash' with 'sh' in the shebang.

  If the question is why Jude replaced /bin/sh with /bin/dash 
in the
middle of the development, I think it was to make sure to not 
invoke

bash. But (sorry for the repetition) I used to modify the shebang
everytime I tested a new version, and there was never any issue 
with

the shell.

There is no question here. *If* the script in question uses dash
spuriously, ie, it doesn't use features specific to dash but is 
actually

a Bourne shell script, replacing /bin/dash with /bin/sh should be
fine. If not, stuff is going to break sooner or later, either 
because

/bin/sh isn't really dash (eg, someone might use bash for that) or
because of difference between the busybox and Debian (d)ash forks.


 There shouldn't be any "feature specific to dash", by
construction.
There are, "by construction". Eg, dash supports local, the POSIX 
/bin/sh

doesn't.
Then it seems Jude's scripts don't use that feature, and they 
shouldn't.



If you check *.sh in vdev/vdevd/helpers/LINUX on git they use local




I dug up some very old correspondence I had with Jude regarding why he 
uses dash


I said

"however I dont have dash on my system so I
had to symlink it to bash to make vdev run
vdevd/helpers/LINUX/*.sh files"

Here is what he said then 2015-05-22 06:25

"That should be temporary.  I'm currently going through the scripts to 
make sure they work with Devuan's system shell (dash).  When I create 
the "-release" branch, I will switch back to #!/bin/sh."




/Scooby

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


Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage)

2016-02-29 Thread shraptor

Due to real(boring?) work I've had not much time to put in on
this.

I did get devuan-jessie-amd64-alpha4-netboot.iso installed in a 
VirtualBox VM.

This went without problems.


Jude had already done some basic package-building that is present on 
git.



However me who never ever ran debian and are somewhat unfamiliar with
init here ran into problem getting vdev to run at start up?

I tried putting it into /etc/rcS.d that is a link here to a startup 
script

in /etc/init.d

But when I get to slim-login manager I get no keyboard.

Seems to try to start vdev when choosing systemd boot alternative but no
evidence of start with eudev that I could see?

If I boot to prompt vdev --once seems to run OK allthough not on /dev
which could be due to devtmpfs mounted?

Any input? anyone more familiar with devuan init.


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


Re: [DNG] Packaging Vdev

2016-03-20 Thread shraptor

On 2016-03-20 15:45, Didier Kryn wrote:

Le 20/03/2016 10:35, Daniel Reurich a écrit :

   I agree that there is little point in putting
effort into packaging something that isn't currently in a functional
state.  If you could share the details of your testing so people can
replicate and perhaps help with the development that would mean that
this discussion has not been useless, but instead useful in teasing 
out

details that at least I had previously missed.

Thank you for this vital update Didier;-)


I have sometimes difficulties to express things in an understandable 
way :-)


I expect Jude has tested his last version and I suspect he did it with
the files under /usr/local and it worked. On my side, I tested it
under the FHS but with a different OS and it failed. I dunno where the
error is. One possibility is that the problem is in the misplacement
of some file(s) or error in some config file.



What error, what happens or is it merely not working?
Did you check log-files?

Latest version works for me under Arch based OS although there are some
question marks for me regarding using vdev and devtmpfs together but I 
have open

issues on github for those.





Brief inventory of the files installed on my test bench:
/sbin/vdevd
/lib/vdev: 11 executable binaries and 27 scripts
/lib/vdev/hwdb: one script and a squashfs filesystem (maybe left over
from building)
/lib/vdev/hwdb/input: 14 text files
/etc/vdev/ifnames.conf
/etc/vdev/vdevd.conf
/etc/acls: 3 files
/etc/actions: 76 text files

Not only must these more than 150 files be in the right places,
but also vdevd and the other executables must look for them in the
right places.

BTW, any news from Jude?

Didier

___
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] Packaging Vdev

2016-03-21 Thread shraptor

On 2016-03-20 20:57, Didier Kryn wrote:

Le 20/03/2016 19:14, shraptor a écrit :


I expect Jude has tested his last version and I suspect he did it 
with

the files under /usr/local and it worked. On my side, I tested it
under the FHS but with a different OS and it failed. I dunno where 
the

error is. One possibility is that the problem is in the misplacement
of some file(s) or error in some config file.



What error, what happens or is it merely not working?
Did you check log-files?


The disks are not detected. They were in pretty all earlier
versions. The log is really HUGE and detecting errors in it is
difficult. If you're used to it, I can send it to you.



Latest version works for me under Arch based OS although there are 
some
question marks for me regarding using vdev and devtmpfs together but I 
have open

issues on github for those.


I'm surprised because I had to fix some source files to be able to
compile it.



Now you got me interested, do you remember which ones?






 Didier


___
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] Packaging Vdev

2016-03-21 Thread shraptor

On 2016-03-21 16:04, shraptor wrote:

On 2016-03-20 20:57, Didier Kryn wrote:

Le 20/03/2016 19:14, shraptor a écrit :


I expect Jude has tested his last version and I suspect he did it 
with

the files under /usr/local and it worked. On my side, I tested it
under the FHS but with a different OS and it failed. I dunno where 
the

error is. One possibility is that the problem is in the misplacement
of some file(s) or error in some config file.



What error, what happens or is it merely not working?
Did you check log-files?


The disks are not detected. They were in pretty all earlier
versions. The log is really HUGE and detecting errors in it is
difficult. If you're used to it, I can send it to you.



Latest version works for me under Arch based OS although there are 
some
question marks for me regarding using vdev and devtmpfs together but 
I have open

issues on github for those.


I'm surprised because I had to fix some source files to be able to
compile it.



Now you got me interested, do you remember which ones?


To be sure I just cloned vdev from git and compiled == worked.

I don't use the targets fs and hwdb though so maybe it was here
you encountered a problem?










 Didier


___
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] Packaging Vdev - compilation errors and patch

2016-03-22 Thread shraptor

On 2016-03-22 09:10, Didier Kryn wrote:

Le 21/03/2016 16:12, shraptor a écrit :

On 2016-03-21 16:04, shraptor wrote:

On 2016-03-20 20:57, Didier Kryn wrote:

Le 20/03/2016 19:14, shraptor a écrit :


I expect Jude has tested his last version and I suspect he did it 
with

the files under /usr/local and it worked. On my side, I tested it
under the FHS but with a different OS and it failed. I dunno where 
the
error is. One possibility is that the problem is in the 
misplacement

of some file(s) or error in some config file.



What error, what happens or is it merely not working?
Did you check log-files?


The disks are not detected. They were in pretty all earlier
versions. The log is really HUGE and detecting errors in it is
difficult. If you're used to it, I can send it to you.



Latest version works for me under Arch based OS although there are 
some
question marks for me regarding using vdev and devtmpfs together 
but I have open

issues on github for those.


I'm surprised because I had to fix some source files to be able 
to

compile it.



Now you got me interested, do you remember which ones?


To be sure I just cloned vdev from git and compiled == worked.


I also have an unsoved problem with fs, but let's ignore it for
now because fs is only a goodie.

Here is the compilation error:


kryn@apcnb98:~/Applications/vdev-plus/vdev$ gcc --version
gcc (Debian 4.6.3-14) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.

kryn@apcnb98:~/Applications/vdev-plus/vdev$ make -C vdevd
[...]
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In
function `vdev_device_request_to_env':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:257: undefined
reference to `major'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:268: undefined
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In
function `vdev_device_add':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined
reference to `major'
... same for several functions.



With

 > gcc --version
gcc (GCC) 5.2.0
...


and then

git clone https://github.com/jcnelson/vdev

I get

https://gist.github.com/suedi/71d374d6f7925c5999e9#file-vdevd_compilation_output


with no errors when issuing make -C vdevd


and then tried

git clone https://git.devuan.org/unsystemd/vdev.git

and make -C vdevd still worked
allthough looking at the last commit the repos are not fully 
synchronized.



Where did you put your patches?





This is corrected by my first patch, include-sysmacros.diff
The two other patches allow the user to provide additional CFLAGS
and/or LDFLAGS to better control building, for example to build
statically or to provide librabies in non-standard places.


Since I don't see your patches as pull requests on 
https://github.com/jcnelson/vdev
maybe that means you are using the devuan repo?? and it is not 
synchronized with

main repo??





Didier

___
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] Packaging Vdev - compilation errors and patch

2016-03-22 Thread shraptor

On 2016-03-22 19:06, aitor_czr wrote:

On 03/22/2016 05:01 PM, aitor_czr wrote:


On 03/22/2016 04:35 PM, shraptor  wrote:

With


gcc --version

gcc (GCC) 5.2.0
...

and then

git clone https://github.com/jcnelson/vdev

I get



https://gist.github.com/suedi/71d374d6f7925c5999e9#file-vdevd_compilation_output


with no errors when issuing make -C vdevd

and then tried

git clone https://git.devuan.org/unsystemd/vdev.git

and make -C vdevd still worked
allthough looking at the last commit the repos are not fully
synchronized.

Where did you put your patches?



This is corrected by my first patch, include-sysmacros.diff
The two other patches allow the user to provide additional CFLAGS
and/or LDFLAGS to better control building, for example to build
statically or to provide librabies in non-standard places.


Since I don't see your patches as pull requests on
https://github.com/jcnelson/vdev
maybe that means you are using the devuan repo?? and it is not
synchronized with
main repo??


I can build succesfully vdevd, libvdev, libudev-compat, hwdb, pstat
and fskit in jessie (gcc-4.9.2). The only one i can't build is vdevfs
because the compiler can't find , contained in the fskit's
headers (vdevfs invokes to ):

$ make -C fs
make: Entering directory '/home/aitor/-VDEV/vdev/fs'
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I.
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/acl.o" -c
"acl.c"
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I.
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/main.o" -c
"main.c"
In file included from /usr/include/fskit/fskit.h:25:0,
 from fs.h:27,
 from main.h:26,
 from main.c:22:
/usr/include/fskit/common.h:63:20: fatal error: iostream: No such file
or directory
 #include 
^
compilation terminated.

It's curious, because i have no issue building fskit. I'm having a
look at buildconf.mk

  Aitor.
Solved doing:

CC:=g++

in the Makefile. Even though i get some errors:

[...]

fs.c:142:28: error: ‘fskit_entry_new’ was not declared in this
scope
child = fskit_entry_new();
^
fs.c:152:93: error: invalid conversion from ‘__uid_t {aka unsigned
int}’ to ‘const char*’ [-fpermissive]
   rc = fskit_entry_init_file( child, sb.st_ino, sb.st_uid,
sb.st_gid, sb.st_mode & 0777 );



I cloned latest from github.com/jcnelson/libpstat  
github.com/jcnelson/fskit and github.com/jcnelson/vdev


did

make
make install


on all three consequtively


All built without errors for me and that includes vdevfs






[...]

Ok, Jude Nelson advised:

*The vdev_subprocess error comes from trying to build vdevfs, an
optional add-on to vdev that is still under development and has not
bee sync'ed with some recent changes to the rest of the codebase.  You
can avoid building it with no loss of functionality*

  Aitor



yes but he since did fix that apparently - if you are building from 
gitlab it needs

to be synced with github
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] Building xorg-xvfb with vdev

2016-04-07 Thread shraptor

Wanting to build xorg-server-xvfb without systemd I ran into problem
with linking with vdev

make[5]: Entering directory 
'/root/Downloads/xorg-server-nosystemd/src/xorg-server-1.18.3/hw/xfree86/dixmods'

  CC   xkbVT.lo
  CC   xkbPrivate.lo
  CC   xkbKillSrv.lo
  CCLD libxorgxkb.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[5]: Leaving directory 
'/root/Downloads/xorg-server-nosystemd/src/xorg-server-1.18.3/hw/xfree86/dixmods'

  CCLD Xorg
/usr/bin/ld: cannot find -ludev
collect2: error: ld returned 1 exit status



I am running configure without --enable-config-udev


Anyone know how to get around this?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] suspend

2016-04-13 Thread shraptor

On 2016-04-13 02:13, Steve Litt wrote:

There is a good reason that I have had Rainer's posts filtered
directly to delete for many months.


Me too.


Not me, I think he has knowledge and some interesting comments
although there is some ranting in between





 So none of this kerfuffle
reached my inbox.


Nor my inbox


Others can of course do the same so Rainer can
rant in a cone of silence.


SteveT

Steve Litt
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
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] adblocking using /etc/hosts

2016-06-05 Thread shraptor

...

I mentioned before on this list Pi-hole https://pi-hole.net/ which
does do something like that and is well maintained.
At the moment it is just a script and it will have to be packaged and
such but it works well on all kinds of De*an versions. I have it
running on RPi 2 with Devuan beta and i like it.


Looks cool, I want one of those

does pi-hole work on devuan?

Any info on hardware working best with devuan raspbian?

Will definitely buy and try








Grtz

Nick

___
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] Raspberry Pi 3

2016-07-14 Thread shraptor
I am about to buy a Raspberry Pi and want to go with the latest version 
model 3.


When I check https://files.devuan.org/devuan_jessie_beta/
I only find devuan_jessie_1.0.0-beta_armhf_raspi2.img.xz

Will there be a version for Raspberry Pi 3 or should I buy the Raspberry 
Pi 2 version?


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


Re: [DNG] Raspberry Pi 3

2016-07-15 Thread shraptor

On 2016-07-14 22:22, Jaromil wrote:

our image works perfect on rpi2 and 3, at dyne.org we already use it
in production for a couple of projects.


I came across some rumors of rpi3 having a overheating problem?

Did you notice anything like that in your projects, Mine is gonna
run pretty much all the time.

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


[DNG] Devuan onion address

2016-07-21 Thread shraptor

I cannot reach the onion address of Devuan

http://devuanzuwu3xoqwp.onion

I get a "404 Not Found"

Have it been working before?


In addition I want to ask if the Devuan package repositories  via Tor 
and apt-transport-tor

are reachable?

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


Re: [DNG] vdev

2016-08-05 Thread shraptor

> Anyone here running vdev? I just looked around a bit, but there
> seems to be little activity:


Yes I am running vdev everyday, not on devuan though.



> https://git.devuan.org/unsystemd/vdev/activity

 No news from Jude for almost one year :-(


Yes am missing Jude soarly



Today I gave it a try on an ascii machine, but the README.md that comes
with a "git clone" seems to be outdated. And when following the
instructions on



Tried to hack it in to devuan but ran into unresponsive login manager
with no mouse or keyboard working.

Other guy at vdev github had the same problem.

Could not solve it but it was my first try at devuan,
Have never ran debian either.

Had to give it up.
New job equals no time for fun projects I'm afraid.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] vdev

2016-08-06 Thread shraptor

On 2016-08-06 10:15, aitor_czr wrote:

Hi,

On 08/05/2016 09:09 PM, Joel Roth  wrote:


Didier Kryn wrote:


No news from Jude for almost one year :-(


Commits to vdev on github are as recent as April this year.
Also, I think his continued work depends on feedback from testers.


I'm partial time reading documentation and sources and

considering

rolling my own hotplugger, simpler than vdev - Jude has done an

enormous

work and vdev is a complex software with hundreds of scripts,

too complex

for me.


sysvinit also has lots of scripts!

But vdev has 33 not in helpers/ and all of those are fairly
simple.


Reading uevents from netlink and parsing them is easy, but

I'm not sure

to know what to do with these events. My first conclusion is

that

when there is MODALIAS=something, then I just have to

modprobe a

module's alias
when there is FIRMWARE=something, I just need to transfer

the firmware

by some well defined API
otherwise it is more complicated because there are many

different cases

(not all drivers provide the same uevent contents); but the job

is to

create/delete a device file, and set owner/permissions and

symlinks; but

some devices are neither char nor block (eg network devices) and

I don't

know what to do with them.

For this reason, I'm tempted to clone mdev and only change

the way it is

invoked. mdev is spawned for every uevent through the
/proc/sys/kernel/hotplug mechanism; instead I would prefer one

long-lasting

daemon reading uevents from netlink. The design of mdev makes

full sense for

embeded devices, but not for others.

I'm sure mdev is very well written, because it has been

written,

maintained, and reviewed by highly skilled professionals. I have

also found

a netlink reader at Skarnet, which is certainly written with

great care but

does not seem very usefull since it just forwards the uevents to

standard

output as they come; but It might be instructive to look if it

uses any

special trick to read the netlink.

Any suggestions are welcome - there are still a lot of

devices I don't

know anything about.


It's your decision to write your own. However Jude's work is
technically interesting, and can be tested without changing
out udev.

Perhaps it just needs some additional user help in the form
of documentation, tutorials, etc.

have fun,

Joel


As i announced yersterday in the IRC Channel, i just uploaded the
repository of gnuinos containing (in addition to linux-libre-4.6.2 and
simple-netaid) the packages of vdev:

deb http://packages.gnuinos.org/ jessie main
deb-src http://packages.gnuinos.org/ jessie main



So does it work with devuan then?

Can you go past the login screen?




Linux-libre has been built using libudev-dev. Now, i'll try it again
using Jude Nelson's *libudev-compat* (which should be recalled to
libudev-compat-dev ?? ), instead of libudev-dev.

I also should add the following line to debian/control:

Provides: libudev-dev

Cheers,

  Aitor.


___
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

2016-08-07 Thread shraptor

As i announced yersterday in the IRC Channel, i just uploaded the
repository of gnuinos containing (in addition to linux-libre-4.6.2

and

simple-netaid) the packages of vdev:

deb http://packages.gnuinos.org/ jessie main
deb-src http://packages.gnuinos.org/ jessie main


So does it work with devuan then?

Can you go past the login screen?

The login screen? What are you referring to?

   Aitor.



OK I was not using your vdev package but a hacked in git version of 
vdev.


If I do "vdev --once ..." I get device files in the designated directory 
however at reboot with vdev when I get
to loginmanager - Is it slim in devuan? Anyway at this login view I have 
no keyboard or mouse.


Now I have had some problems with devtmpfs and vdev on another OS? Not 
sure this is the problem though?


This guy seems to be getting the same behavior as me
https://github.com/jcnelson/vdev/issues/99

I was interested if you were getting the same behavior or if you had 
found a solution?

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


Re: [DNG] vdev

2016-08-07 Thread shraptor



FWIW, I know very little about Devuan package building, so I jumped
straight to compiling the github source for vdev, and installing from
it. After just a couple of tweaks of the runtime and  initramfs
configurations, I've made a successful replacement on a pristine
Devuan 1.0.0 install, with the 3.16.0-4-amd64 kernel.

Of course I don't know anything about how complete it is in respect of
handling all sorts of devices.


By any chance you could share procedure since I tried the same and 
failed?


Not git and compiling of course but how you got it to cooperate with 
Devuan


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


Re: [DNG] vdev - scanner

2016-08-16 Thread shraptor

I got the scanner working.

If I boot with udev, the scanner works, and the permissions on the 
device

look like this:

ls -l /dev/bus/usb/002/
crw-rw-r--+ 1 root root 189, 137 Aug 16 10:30 010

and with vdev, it looks like this:
crw--- 1 root root 189, 131 Aug 16 10:39 004

I changed the permissions and added myself to the scanner group (oops!)
and now xsane finds the scanner when I'm running vdev. I hope someone
knows what to do with this information, because I'm in new territory 
here.

(and I don't know C.)

If udevadm output for the scanner would help, I'll post it. The udev 
rules

for scanners are in /lib/udev/rules.d/60-libsane.rules



Maybe you should write a vdev action for your scanner
on my system they actions are in /etc/vdev/actions

for instance optical.act contains

[vdev-action]
event=any
path=^sr[0-9]*$
VAR_OPTICAL_OWNER=root
VAR_OPTICAL_GROUP=optical
VAR_OPTICAL_MODE=0660
helper=optical.sh
daemonlet=true
if_exists=run



No C is needed. Write something that matches path like for optical 
path=^sr[0-9]*$

then set needed permissions and group and vdev will fix it for you


When you succeed you may contribute that .act file for others, yeah?





-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 - scanner

2016-08-16 Thread shraptor

On 2016-08-16 18:11, shraptor wrote:

I got the scanner working.

If I boot with udev, the scanner works, and the permissions on the 
device

look like this:

ls -l /dev/bus/usb/002/
crw-rw-r--+ 1 root root 189, 137 Aug 16 10:30 010

and with vdev, it looks like this:
crw--- 1 root root 189, 131 Aug 16 10:39 004

I changed the permissions and added myself to the scanner group 
(oops!)

and now xsane finds the scanner when I'm running vdev. I hope someone
knows what to do with this information, because I'm in new territory 
here.

(and I don't know C.)

If udevadm output for the scanner would help, I'll post it. The udev 
rules

for scanners are in /lib/udev/rules.d/60-libsane.rules



Maybe you should write a vdev action for your scanner
on my system they actions are in /etc/vdev/actions

for instance optical.act contains

[vdev-action]
event=any
path=^sr[0-9]*$
VAR_OPTICAL_OWNER=root
VAR_OPTICAL_GROUP=optical
VAR_OPTICAL_MODE=0660
helper=optical.sh
daemonlet=true
if_exists=run



No C is needed. Write something that matches path like for optical
path=^sr[0-9]*$
then set needed permissions and group and vdev will fix it for you


When you succeed you may contribute that .act file for others, yeah?



Maybe you can use something like null.act

[vdev-action]
event=add
path=^null$
VAR_PERMISSIONS_MODE=0666
helper=permissions.sh
if_exists=run



I mean the permissions.sh


so something like

scanner.act

[vdev-action]
event=add
path=^null$
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run

Dunnow wot path you should use but maybe you could figure it out?







-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] vdev - scanner

2016-08-16 Thread shraptor

On 2016-08-16 18:19, shraptor wrote:

On 2016-08-16 18:11, shraptor wrote:

I got the scanner working.

If I boot with udev, the scanner works, and the permissions on the 
device

look like this:

ls -l /dev/bus/usb/002/
crw-rw-r--+ 1 root root 189, 137 Aug 16 10:30 010

and with vdev, it looks like this:
crw--- 1 root root 189, 131 Aug 16 10:39 004

I changed the permissions and added myself to the scanner group 
(oops!)

and now xsane finds the scanner when I'm running vdev. I hope someone
knows what to do with this information, because I'm in new territory 
here.

(and I don't know C.)

If udevadm output for the scanner would help, I'll post it. The udev 
rules

for scanners are in /lib/udev/rules.d/60-libsane.rules



Maybe you should write a vdev action for your scanner
on my system they actions are in /etc/vdev/actions

for instance optical.act contains

[vdev-action]
event=any
path=^sr[0-9]*$
VAR_OPTICAL_OWNER=root
VAR_OPTICAL_GROUP=optical
VAR_OPTICAL_MODE=0660
helper=optical.sh
daemonlet=true
if_exists=run



No C is needed. Write something that matches path like for optical
path=^sr[0-9]*$
then set needed permissions and group and vdev will fix it for you


When you succeed you may contribute that .act file for others, yeah?



Maybe you can use something like null.act

[vdev-action]
event=add
path=^null$
VAR_PERMISSIONS_MODE=0666
helper=permissions.sh
if_exists=run



I mean the permissions.sh


so something like

scanner.act

[vdev-action]
event=add
path=^null$



VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run

Dunnow wot path you should use but maybe you could figure it out?



perhaps?

scanner.act

[vdev-action]
event=add
path=^bus/usb/1$
VAR_OWNER=root
VAR_GROUP=scanner
VAR_PERMISSIONS_MODE=0664
helper=permissions.sh
if_exists=run


Does debian use something like /dev/usbscanner0 or /dev/usb/scanner0?
Then maybe a new helper scanner.sh is needed, like optical.sh?

In the beginning of vdev creation we dreamt of a udev rules to vdev 
action parser












-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] vdev packaging

2016-08-26 Thread shraptor

On 2016-08-25 14:06, Ralph Ronnquist wrote:

So, I took the steps of forking Jude Nelson's vdev on git.devuan.org,
and augmenting it with an initial set up for deb package building.

I set it up as three deb's:
   libudev1-compat to replace libudev1,
   vdevd being the daemon, and
   vdev being the configuration, initramfs building and the set up as
sysvinit startup script.

I've built sample packages for amd64, and tested on a pristine Devuan
1.0.0, (with DE+Xfce, printer server and ssh server). Available at

https://git.devuan.org/ralph.ronnquist/vdev/release

If you download those and install together (as in dpkg -i *.deb), your
system will change into using vdev rather than udev, but it doesn't
uninstall udev for you. It "only" removes udev's sysvinit scripts, and
udev's configuration for initramfs building, and the "init" script
(replaces the one from initramfs-tools).

When installing, it might warn about volume symlinks not being
created. It's is safe to ignore this. Alternatively you install lvm2
first.

You can also build your own deb's by cloning
https://git.devuan.org/ralph.ronnquist/vdev

and using
$ make -f debian.mk

provided you have dh_make and dpkg-buildpackage, as well as
build-essential. Since I'm quite new to package building, it only
contains the bare-bones so far. There are also no upstream changes to
source other than to Makefile's and initramfs scripts, with the
exception of the very minor patch to
vdevd/helpers/LINUX/udev-compat.sh.

As a side note, eventually I realised that the main issue why the
keyboard didn't work, was that the evdev module didn't get installed,
and that it needs to be installed before /dev/input is populated.

Ralph.


Great work Ralph.

I will test it during next week and give feedback.

Since I had a go at making it work meself could you explain how
you went about getting evdev module loaded before /dev/input was 
populated



Also how did you solve the problem with logfile could not be written
at the logfile path?

Just curious and need to learn

/scooby


___
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 packaging

2016-08-26 Thread shraptor

On 2016-08-26 17:41, shraptor wrote:

On 2016-08-25 14:06, Ralph Ronnquist wrote:

So, I took the steps of forking Jude Nelson's vdev on git.devuan.org,
and augmenting it with an initial set up for deb package building.

I set it up as three deb's:
   libudev1-compat to replace libudev1,
   vdevd being the daemon, and
   vdev being the configuration, initramfs building and the set up as
sysvinit startup script.

I've built sample packages for amd64, and tested on a pristine Devuan
1.0.0, (with DE+Xfce, printer server and ssh server). Available at

https://git.devuan.org/ralph.ronnquist/vdev/release

If you download those and install together (as in dpkg -i *.deb), your
system will change into using vdev rather than udev, but it doesn't
uninstall udev for you. It "only" removes udev's sysvinit scripts, and
udev's configuration for initramfs building, and the "init" script
(replaces the one from initramfs-tools).

When installing, it might warn about volume symlinks not being
created. It's is safe to ignore this. Alternatively you install lvm2
first.

You can also build your own deb's by cloning
https://git.devuan.org/ralph.ronnquist/vdev

and using
$ make -f debian.mk

provided you have dh_make and dpkg-buildpackage, as well as
build-essential. Since I'm quite new to package building, it only
contains the bare-bones so far. There are also no upstream changes to
source other than to Makefile's and initramfs scripts, with the
exception of the very minor patch to
vdevd/helpers/LINUX/udev-compat.sh.

As a side note, eventually I realised that the main issue why the
keyboard didn't work, was that the evdev module didn't get installed,
and that it needs to be installed before /dev/input is populated.

Ralph.


Great work Ralph.

I will test it during next week and give feedback.

Since I had a go at making it work meself could you explain how
you went about getting evdev module loaded before /dev/input was 
populated



Also how did you solve the problem with logfile could not be written
at the logfile path?

Just curious and need to learn

/scooby



Also Ralph may I ask if you believe the vdev upgrade would work on rpi3?

rpi3 with really no peripherals as it is used as a server so it probably 
would work

although I don't know how to install the build chain for it.

Probably not a good idea to build vdev on the rpi3 when it is in 
"production", right?


/scooby







___
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] building for armhf

2016-08-30 Thread shraptor

I want to build packages for a rpi3

I wonder if there is something to re-use from

https://git.devuan.org/devuan/arm-sdk

It is used in auto-build of devuan iso for rpi.


In the instruction for arm-sdk If I follow the recipe down to

; init devuan raspi2



Am I close to having an environment for buildin packages for armhf?

Maybe there is some script there I could spy on for info?



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


Re: [DNG] vdev packaging

2016-08-30 Thread shraptor

On 2016-08-28 12:36, fsmithred wrote:

On 08/27/2016 11:13 PM, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 28/08/16 11:37:


fsmithred wrote on 28/08/16 01:12:

...

Sadly, I'm not getting Ralph's i386 build to boot. It's hanging on 
usb
(keyboard). Any time I type, I get a usb disconnect and connect 
message.




I'm afraid it was a worse problem. I had updated (improved) the
initramfs hook and then packaged it all without proper testing. This
also affected the amd64 version, which thus fails to build the initrd
properly. The amd64 packages are now corrected, and I'll also update 
the

i386 packages shortly.

If on inspection you find /usr/share/initramfs-tools/hooks/vdev being
non-executable, you should refetch vdev_1.0beta-1_amd64.deb (or all 
of
them) and reinstall. (If it already is executable, you have the 
initial

release, i.e., without the improved script, and can thus sit back to
enjoy life as usual)


Corrected packages available at the same place as before:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Note that there is now an explicit dependency on makedev, which might
cause a slight hiccup for an i386 installation. If so, a normal 
"apt-get

-f install" will sort it out.

Ralph.


The corrected amd64 packages work. I just downloaded, installed and
rebooted with the new initrd. Smooth as silk.



smooth a silk indeed, Good Job Mr, Ronnquist.

Am happy now!

Tried it in a virtualbox install, will set up one of my comps
with devuan now so I can run it for real.

Can't wait to get it on my rpi3 :)



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


Re: [DNG] vdev packaging

2016-08-30 Thread shraptor

On 2016-08-30 21:13, shraptor wrote:

On 2016-08-28 12:36, fsmithred wrote:

On 08/27/2016 11:13 PM, Ralph Ronnquist wrote:

Ralph Ronnquist wrote on 28/08/16 11:37:


fsmithred wrote on 28/08/16 01:12:

...

Sadly, I'm not getting Ralph's i386 build to boot. It's hanging on 
usb
(keyboard). Any time I type, I get a usb disconnect and connect 
message.




I'm afraid it was a worse problem. I had updated (improved) the
initramfs hook and then packaged it all without proper testing. This
also affected the amd64 version, which thus fails to build the 
initrd
properly. The amd64 packages are now corrected, and I'll also update 
the

i386 packages shortly.

If on inspection you find /usr/share/initramfs-tools/hooks/vdev 
being
non-executable, you should refetch vdev_1.0beta-1_amd64.deb (or all 
of
them) and reinstall. (If it already is executable, you have the 
initial

release, i.e., without the improved script, and can thus sit back to
enjoy life as usual)


Corrected packages available at the same place as before:
https://git.devuan.org/ralph.ronnquist/vdev/tree/master/release

Note that there is now an explicit dependency on makedev, which might
cause a slight hiccup for an i386 installation. If so, a normal 
"apt-get

-f install" will sort it out.

Ralph.


The corrected amd64 packages work. I just downloaded, installed and
rebooted with the new initrd. Smooth as silk.



smooth a silk indeed, Good Job Mr, Ronnquist.

Am happy now!

Tried it in a virtualbox install, will set up one of my comps
with devuan now so I can run it for real.

Can't wait to get it on my rpi3 :)



/scooby



Tried to setup the arm-sdk on vbox devuan with vdev

Getting a lot of errors about udev, guess that is to be expected at this 
stage.


does the vdev packages "provides" udev?

including full output of apt-get command below

Guess I have todo the arm-sdk stuff on a vanilla devuan for now.


/scooby



# apt-get install build-essential gnupg2 debootstrap curl rsync 
gcc-arm-none-eabi parted kpartx qemu-user-static sudo git-core parted 
gcc-multilib lib32z1 u-boot-tools device-x32gcc-4.9-dev libx32gcc1

  libx32gomp1 libx32itm1 libx32quadmath0 libx32ubsan0
Suggested packages:
  libnewlib-doc
The following NEW packages will be installed:
  binutils-arm-none-eabi cgpt debootstrap device-tree-compiler
  gcc-4.9-multilib gcc-arm-none-eabi gcc-multilib git-core kpartx 
lib32asan1
  lib32atomic1 lib32cilkrts5 lib32gcc-4.9-dev lib32gcc1 lib32gomp1 
lib32itm1
  lib32quadmath0 lib32stdc++6 lib32ubsan0 lib32z1 libc6-dev-i386 
libc6-dev-x32

  libc6-i386 libc6-x32 libnewlib-arm-none-eabi libnewlib-dev
  libstdc++-arm-none-eabi-newlib libx32asan1 libx32atomic1 
libx32cilkrts5

  libx32gcc-4.9-dev libx32gcc1 libx32gomp1 libx32itm1 libx32quadmath0
  libx32ubsan0 lzop qemu-user-static u-boot-tools
0 upgraded, 39 newly installed, 0 to remove and 4 not upgraded.
5 not fully installed or removed.
Need to get 14.8 MB/81.0 MB of archives.
After this operation, 584 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://auto.mirror.devuan.org/merged/ jessie/main libc6-i386 amd64 
2.19-18+deb8u4 [2,377 kB]
Get:2 http://auto.mirror.devuan.org/merged/ jessie/main libc6-dev-i386 
amd64 2.19-18+deb8u4 [1,319 kB]
Get:3 http://auto.mirror.devuan.org/merged/ jessie/main libc6-x32 amd64 
2.19-18+deb8u4 [2,603 kB]
Get:4 http://auto.mirror.devuan.org/merged/ jessie/main libc6-dev-x32 
amd64 2.19-18+deb8u4 [1,587 kB]
Get:5 http://auto.mirror.devuan.org/merged/ jessie/main git-core all 
1:2.1.4-2.1+deb8u2 [1,496 B]
Get:6 http://auto.mirror.devuan.org/merged/ jessie/main qemu-user-static 
amd64 1:2.1+dfsg-12+deb8u6 [6,913 kB]

Fetched 14.8 MB in 7s (1,852 kB/s)
Extracting templates from packages: 100%
Selecting previously unselected package libc6-i386.
(Reading database ... 101777 files and directories currently installed.)
Preparing to unpack .../libc6-i386_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-i386 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-dev-i386.
Preparing to unpack .../libc6-dev-i386_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-dev-i386 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-x32.
Preparing to unpack .../libc6-x32_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-x32 (2.19-18+deb8u4) ...
Selecting previously unselected package libc6-dev-x32.
Preparing to unpack .../libc6-dev-x32_2.19-18+deb8u4_amd64.deb ...
Unpacking libc6-dev-x32 (2.19-18+deb8u4) ...
Selecting previously unselected package lib32gcc1.
Preparing to unpack .../lib32gcc1_1%3a4.9.2-10_amd64.deb ...
Unpacking lib32gcc1 (1:4.9.2-10) ...
Selecting previously unselected package libx32gcc1.
Preparing to unpack .../libx32gcc1_1%3a4.9.2-10_amd64.deb ...
Unpacking libx32gcc1 (1:4.9.2-10) ...
Selecting previously unselected package lib32gomp1.
Preparing to unpack .../lib32gomp1_4.9.2-10_amd64.deb ...
Unpacking lib32gomp1 (4.9.2-10) ...
Selecting previously u

Re: [DNG] building for armhf

2016-08-31 Thread shraptor

On 2016-08-31 09:21, Jaromil wrote:

for package building we are still using the "legacy" arm-sdk scripts,
the SDK is still work in progress that should merge all the efforts
going in the same direction by parazyd, katolaz and me

to re-build packages you need to setup jenkins with the
devuan-jenkins-glue and qemu using with pinthread. you may also want
to freeze your own build toolchain. this is all not documented yet.


That is old greek to me unfortunately.


pinthread   I guess is this one https://github.com/nexlab/pinthread
and the USAGE seems pretty OK for me to follow.



devuan-jenkins-glue  
https://git.devuan.org/devuan-infrastructure/jenkins-debian-glue
 and I could check http://jenkins-debian-glue.org/ 
to get a notion what its

 doing


jenkins  Jenkins Continuous Integration system. I could read here
  http://www.vogella.com/tutorials/Jenkins/article.html



I could use some more pointers are there some scripts I could spy on?
I mean how it all fits together?

I guess this is not prioritized but do you think it will be documented 
any time in the future?



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


Re: [DNG] building for armhf

2016-09-01 Thread shraptor

...


we of course intend to document all steps needed to setup the CI,
something we can expect to be accomplished in the first quarter of
2017, so that people can also build their own.


So is this the only way to setup a tool chain for armhf on devuan?

I got to research some more.

I only want to rebuild a couple of packages




however it is not a priority now, nor it is a priority to have rpi3
specific packages. we decided some time ago that rpi2 packages are
just fine and work on both, while there are little advantages in
dropping the rpi2 compatibility. I'd be interested in reading your
motivation to have rpi3 specific builds.


I agree with packages working on both rpi2 and rpi3,
Sorry you get no arguments from me on that.

My motivation for rebuilding packages for rpi was

1.) Rebuild tor package to the newest version. I want to run the latest 
tor software

Probably important for privacy of users of the onion network, right?

Official tor builds will pull in libsystemd0

2.) Yearn to run vdev on my rpi.



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


Re: [DNG] Raspberry Pi 2 and other ARM based credit card computers

2016-09-01 Thread shraptor

On 2016-09-01 16:21, Thomas Besser wrote:

Am 01.09.2016 um 16:18 schrieb Thomas Besser:

Started generating my own image with arm-sdk.

In which git source I should post issues? git.devuan.org or 
github.com?

Why are existing both sources?

BTW I started a wiki entry for "Devuan on Raspberry Pi" for collecting
informations for others. From time to time I will add my efforts 
there.


Ups, sorry forgot the url ;-)

http://wiki.friendsofdevuan.org/doku.php/rpi


Yeah I had a hard time finding it.

But during search I found this document by florian

https://cheatsheet.zwischenspeicher.info/2016/05/11-2016-05-05/


That possibly could be linked on the wiki as per his own wishes here
https://lists.dyne.org/lurker/message/20160507.161708.e0a1a8ff.nl.html


I want to ask florian here why he disables IPv6 by blacklisting the IPv6 
kernel module?

any security considerations?


Thomas were you able to setup a toolchain for building packages for 
rpi{2,3}


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


Re: [DNG] tor and systemd?

2016-09-01 Thread shraptor

On 2016-09-01 15:51, Hendrik Boom wrote:

On Thu, Sep 01, 2016 at 02:28:04PM +0200, shraptor wrote:


Official tor builds will pull in libsystemd0


How official?  upstream's? or Debian's?


The ones from tor:

deb http://deb.torproject.org/torproject.org jessie main


/scooby

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


Re: [DNG] arm port / Raspberry Pi firmware update

2016-10-25 Thread shraptor

On 2016-10-24 12:01, Florian Zieboll wrote:

Hallo,

although I don't know if you are planning to provide a similar SoC
specific "firmware update" option to the arm port of Devuan:

Some days ago I ran Hexxeh's rpi-update script [1] to update kernel and
firmware of the devuan_jessie_1.0.0-beta_armhf_raspi2.img on a
Raspberry Pi 2B.

It pulls and installs kernel, modules, device tree and firmware blobs
from Hexxeh's rpi-firmware repository [2], which claims to be a partial
mirror of the official raspberrypi.org firmware repo.

So far just FYI: It works without issues, at least for my headless rPi.
(You may have to mount the boot partition before running the script.)



A thousand thanks for this tip Florian.

I was looking for a way to update kernel in the wake of dirtyc0w

Worked a 100% for me as well

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