[Dng] Kali Linux has systemd?
On 2015-02-10 19:52, Wim wrote: Hi, Mark inquired about the source of my info on kali. I just saw kali on the list at: http://without-systemd.org/wiki/index.php/Main_Page#Operating_systems_without_systemd_in_the_default_installation Decided to do some research. Apparently, systemd is already present in the latest kali 1.0.9: https://forums.kali.org/showthread.php?24275-Ran-updates-and-now-no-GUI-at-all https://forums.kali.org/showthread.php?23603-About-Kali-Linux-and-systemd It appears the list isn't up-to-date and they should take kali off. Cheers, Wim I have removed Kali from the wiki since I put it there. But.. I have Kali 1.1.0 (2015-02-09) and can't find systemd in it. I have apt-get updated upgraded. Using [find / -name systemd*] I have found 2 folders 1 file: /etc/systemd /lib/systemd /usr/share/gnome-shell/js/gdm/systemd.js And noticed sysvinit at boot. Can you confirm that systemd is installed in your installation? And if so, how you got it? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Raspberry Pi 2
It doesn't work on a majority of packages, as I understand (build scripts that rely on running compiled code, that don't respect CC, and many other causes.) oh that's dreadful. sounds like something that should be fixed and submitted upstream. --Gravis On Tue, Feb 10, 2015 at 9:49 AM, Isaac Dunham ibid...@gmail.com wrote: On Tue, Feb 10, 2015 at 04:30:30AM -0500, Gravis wrote: to my knowledge, cross compilation has minimal overhead. while having native targets is good for testing, it won't have a significant impact on compile time. It doesn't work on a majority of packages, as I understand (build scripts that rely on running compiled code, that don't respect CC, and many other causes.) You can use qemu, but that's generally ~80% CPU overhead. Thanks, Isaac Dunham ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [Dng] Raspberry Pi 2
Hi Robert and list, I've been reading this list since the beginning. Felt the need to reply to this, but it's only a Me too!. The Raspberry foundation has stated already that they will adopt Jessie as-is, with systemd. Discussion of systemd on the forum is frowned upon. Most threads got closed fairly fast. I would love to see Devan on ARM, or Devuan on Raspberri Pi. Mine are running Raspbian too, although I've been trying out Kali and a couple of others too. Kali seems to be one of the distro's that rejected systemd too. I'm waiting for the dust to clear after the launch of the Pi 2 to buy one. Setting up a Devuan testbed on the Pi would be a very worthwhile cause. Cheers, Wim 2015-02-10 9:18 GMT+01:00 Robert Storey robert.sto...@gmail.com: I just saw this announcement: Raspberry Pi 2 Now on Sale for US$35 http://www.raspberrypi.org/raspberry-pi-2-on-sale/ It will probably be a few months before I can buy one in my part of the world (Taiwan), but it's on my shopping list. Maybe for my birthday (in May). Anyway, it's got an ARM7 processor, so at last there is a Pi that is fast enough to use as a real computer. The relevance for us here on this list is that this looks like a good target for Devuan sometime in the future when we've got a final release. No hurry of course. Just wanted to share the news with other Pi enthusiasts. Right now I'm running Raspbian on mine, but since I imagine they will go systemd (if they haven't already - don't know since I haven't updated) I will definitely be looking for an alternative distro. cheers, 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] Towards systemd-free packages
Hi Jaromil, Thank you for clarifying. I'm sorry if I'm asking questions too early ;) I'll give it another try when you feel like the SDK is ready. I like this workflow a lot, especially the ability to build ISOs (and presumably other bootable media). I look forward to using it to do integration testing in a VM, for example. Regards, -Jude On Tue, Feb 10, 2015 at 4:15 AM, Jaromil jaro...@dyne.org wrote: hi, On Mon, 09 Feb 2015, Jude Nelson wrote: To clarify, the SDK will pull a package from Debian, and create a new branch for each version so maintainers can observe and deal with the changes? yes. If so, then the maintainers (not Jenkins) will be pulling from Debian or upstream and then committing to Devuan's gitlab, thereby keeping Devuan packages in-sync with upstream. Is this the case? yes Maintainers can use git to diff (which is very powerful at that) and the merging must always be done by hand and consciously. We hope to have enough maintainers to cover such tasks which, facilitated in such a way by the SDK and Git, shouldn't be so hard. Jenkins is there only to automate the builds of tested packages that maintainers deem ready for production. the SDK also makes it easy to build the packages locally into chroots and soon will include also a mechanism to toast all the collection into ISO images: a passage that Debian itself is missing to facilitate really if we look at the confusion of docs about debian-installer and burning ISOs. more in general all what is going into Devuan will pass through Git, this way we can all have a clear overview and detailed records of what happens, what goes in there and what not. your comments on this process are very welcome in this stage, as you can see I'm very much in the middle of writing the SDK still and can well integrate new ideas, however the general flow is the one described above. Unrelated, I opened in issue on the SDK.* It seems that I'm prompted for a password for [1]g...@git.devuan.org when I run the init script.* I don't know what to put here. Thanks Ok I'll look into it. Please give it another day or two before considering it ready for testing, just yesterday I've committed a rather big refactoring of the scripts. Passwords are seldom asked (in chroot, build and a few other operations) and in general sudo is used, which is also what schroot is using I understand. I hope Roger Leigh will be happy to see that we made a good use of his handy creation schroot. hack on! ciao -- Jaromil, Dyne.org Free Software Foundry (est. 2000) We are free to share code and we code to share freedom Web: https://j.dyne.org Contact: https://j.dyne.org/c.vcf GPG: 6113 D89C A825 C5CE DD02 C872 73B3 5DA5 4ACB 7D10 Confidential communications: https://keybase.io/jaromil ___ 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] Raspberry Pi 2
that's not cross compiling, that's compiling on an emulator. cross compilers directly generate code for the target platform. A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. For example, a compiler that runs on a Windows 7 PC but generates code that runs on Android smartphone is a cross compiler. --Gravis On Tue, Feb 10, 2015 at 2:33 PM, mutek mu...@riseup.net wrote: Il 10/02/2015 10:30 Gravis ha scritto: to my knowledge, cross compilation has minimal overhead. while having native targets is good for testing, it won't have a significant impact on compile time. agreed, to my experience, cross compilation using qemu-arm-static in an armhf chroot inside an amd64 host (Asus Vivobook S200 i3 1,4GHz 4GB RAM and Debian Wheezy) is a lot faster than working direct into rpi B, same feelings working inside UDOO quad and BPI m ___ 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
