Re: [Dng] About separate mailing lists
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
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
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
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
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
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
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
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
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
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
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)
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?
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)
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)
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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?
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.
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.
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
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?
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
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
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
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.
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.
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
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
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
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
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
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
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)
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)
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)
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)
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)
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)
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)
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)
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
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
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
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
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
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
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
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
... 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
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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
... 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
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?
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
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