Re: [DNG] GTK3 and systemd
On Thu, 04 May 2017, Enrico Weigelt, metux IT consult wrote: > On 04.05.2017 15:58, parazyd wrote: > > > Nope, Gtk3 does depend on dbus. More correctly, its accessibility parts > > depend on dbus. > > What exactly does that 'accessibility' stuff actually do ? It's somewhat a black box. Nobody ever bothered to fork Gtk3 without it, so my guess it's deeply integrated anyway. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GTK3 and systemd
On Thu, 04 May 2017, aitor_czr wrote: >Hi parazyd, >On 05/04/2017 01:15 PM, parazyd [1]<para...@dyne.org> wrote: > > Ok, so vanilla GTK *does* depend on systemd. Well, best start looking for > anothe > r toolkit then i guess... > > GNOME != GTK3. Gtk3 does depend on dbus & co., but does not depend on > systemd. It would be very wrong to do so actually, since a lot of > applications are ported to Gtk3. > >Gtk3 doesn't depend on dbus, whereas some apps like slim, synaptic, >thunar, seahorse, nautilus... But not Gtk per se, neither the Qt >toolkit. >Cheers, > Aitor. Nope, Gtk3 does depend on dbus. More correctly, its accessibility parts depend on dbus. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GTK3 and systemd
On Thu, 04 May 2017, KatolaZ wrote: > On Thu, May 04, 2017 at 11:43:33AM +0200, Radagast wrote: > > Ok, so vanilla GTK *does* depend on systemd. Well, best start looking for > > another toolkit then i guess... > > > > ...or perhaps help maintaining and developing GTK2, which does not > depend on systemd. Hard times ahead, but nobody has ever maganed to > force the entire community to stay on a single path. Remember that > GNOME itself was born as a tentative countermeasure to KDE, which was > using the (then non-free) QT libraries, hence forcing users to abide > to a non-free license from Trolltech... Gtk2 hasn't received an update in years, so it's a relatively safe bet if you choose to use it. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] GTK3 and systemd
On Thu, 04 May 2017, Radagast wrote: > Ok, so vanilla GTK *does* depend on systemd. Well, best start looking for > another toolkit then i guess... GNOME != GTK3. Gtk3 does depend on dbus & co., but does not depend on systemd. It would be very wrong to do so actually, since a lot of applications are ported to Gtk3. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ARMv8 Cloud servers
On Fri, 28 Apr 2017, info at smallinnovations dot nl wrote: >Scaleway announced yesterday their ARMv8 Cloud servers (from ARM64-2GB >2xARMv8 cores and 50Gb SSD and up). > >I like the price (starting at € 2.99/mo) but at the moment they only >support Ubuntu 16.04 LTS. I want of course to run Devuan and that >should be possible: > >--Quote: > >If you wish to support ARMv8 on your open source project, drop us a >line at [1]opensou...@scaleway.com, we might be able to help! > >--End Quote > >Anyone having experience with Cavium ThunderX SoC? And knows what is >needed to get this SoC supported by Devuan? > >Grtz > >Nick If you can provide me with the board, I could probably get it running. Making images for it blindly could end up being a very time-consuming process. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] (testing) sunxi ARM images
Hi all! Since today there is an experimental new armhf image available for download. It can be found here: https://files.devuan.org/devuan_jessie_rc/embedded/testing/ This image is a generic image aimed at sunxi (allwinner) boards. I'm trying to get the same image working with multiple boards, and the currently supported boards can be found here: https://github.com/dyne/arm-sdk/blob/next/config#L75 Right now it's 23 different boards, but I am happy to accept requests for other Allwinner boards if you're in need of any. The concept of this image is that it contains all the device trees in itself, and the u-boot blobs are provided for download for the specific board being used. It's explained in the README.txt file along with the image. Happy hacking! -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..setnet.sh, wicd and heads-0.2 scorn, was:..vdev box recovery ideas?
On Mon, 24 Apr 2017, Arnt Karlsen wrote: > On Mon, 24 Apr 2017 13:25:09 +0100, KatolaZ wrote in message > <20170424122509.gt14...@katolaz.homeunix.net>: > > > On Mon, Apr 24, 2017 at 03:05:42AM +0200, Arnt Karlsen wrote: > > > On Wed, 19 Apr 2017 22:47:59 +0100, KatolaZ wrote in message > > > <20170419214759.gc14...@katolaz.homeunix.net>: > > > > > > > On Wed, Apr 19, 2017 at 11:37:32PM +0200, Arnt Karlsen wrote: > > > > > > > > [cut] > > > > > > > > > > > > > > ..what nasty command line tricks do I use to get online with > > > > > devuan_jessie_RC_amd64_minimal_live_vdev.iso? > > > > > (Ideally wifi, but eth0 will work.) > > > > > > > > > > > > > > > > > Hi Arnt, > > > > > > > > if it comes from a minimal-live RC, you have setnet in there. Just > > > > run: > > > > > > > > # setnet.sh > > > > > > > > It also has a manpage, but simple comfiguration should be pretty > > > > straightforward. Any feedback is welcome. > > > > > > ..setnet.sh works nicely, but it and wicd should check for unchanged > > > default passwords and _refuse_ to go online until you do the "passwd > > > passwd devuan ||passwd heads " dance, espescially since we're here > > > because we don't trust systemd endpoint security in e.g. Tails-2.12. > > > > > > > uh? setnet and wicd are just *tools*, which allow to facilitate the > > interaction with *mechanisms* related to network configuration. > > > > What you are asking for (refuse to put a machine online if the > > password of a given user is such and such) is a *policy*, which has > > nothing to do with tools, since it ultimately (and rightfully) stays > > in the hands of the system administrator. > > ...who in the case of Tails and heads admins, might be the clueless > Ed Snowden types we wanna keep alive. Snowden is far from clueless. He might be a shill, but he's far from clueless. > ..we don't warn them before we drop them online on wired networks with > heads-0.2. > The vdev iso does this right though, it stays offline until you e.g. > run setnet.sh. > > ..I agree this is a policy issue, and we should set it so at least > clueless heads-0.2 etc people stay offline until they change their > passwords away from the default ones. heads only connects to the Internet if there is a way for it to connect. If your ethernet cable is out, you won't be online. And if you have your ethernet cable plugged in, the expected behaviour is to connect to the Internet. > > Most of the problems we are facing nowadays with bloated software and > > ill-defined hypercomplicated solutions to non-existing problems is the > > lack of recognition that mechanisms and policy *must* remain separate. > > > > If a user does not understand that putting their machine online with a > > devuan/devuan user might be a security risk, there is no automagic > > tool that case save their ass. > > > > Knowledge is the cure. Automagic is just dust in your eyes, and > > enormous PITAs when somethings goes wrong. > > ..I have the Knowledge, but still found myself Automagically Online > with heads-0.2's Default Passwords, Because I Forgot I still had the > network wire plugged in on boot-up. I'm just a human who err. ;o) > In my case, this endpoint security breach was no problem. > But that same blunder could kill any needy heads user. > Which is why heads offers no way of remote login by default. We also have grsec doing its job for us. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help to create iso image
On Mon, 27 Mar 2017, Ismael L. Donis Garcia wrote: > - Original Message - > From: "parazyd" <para...@dyne.org> > To: "Ismael L. Donis Garcia" <sli...@natio.co.cu> > Cc: <dng@lists.dyne.org> > Sent: Monday, March 27, 2017 7:51 AM > Subject: Re: [DNG] Help to create iso image > > > > On Mon, 27 Mar 2017, Ismael L. Donis Garcia wrote: > > > >> - Original Message - > >> From: "Steve Litt" <sl...@troubleshooters.com> > >> To: <dng@lists.dyne.org> > >> Sent: Saturday, March 25, 2017 11:07 AM > >> Subject: Re: [DNG] Help to create iso image > >> > >> > >> > On Fri, 24 Mar 2017 14:59:57 -0500 > >> > "Ismael L. Donis Garcia" <sli...@natio.co.cu> wrote: > >> > > >> > > >> >> I want to create an iso of lxqt i386 for ascci with as little as > >> >> possible, but that is operative and pleasing to the eye at the same > >> >> time. > >> > > >> > For the pleasing to the eye part, you should consult golinux, who is a > >> > gifted designer. > >> > > >> > SteveT > >> > > >> > Steve Litt > >> > March 2017 featured book: Troubleshooting: Why Bother? > >> > http://www.troubleshooters.com/twb > >> > >> Thank you very much, I'll try to get in touch with him. > >> > >> I want to see if I can help in anything to devuan. > >> > >> And try to do something that is useful to others. > >> > >> As I see that nobody made ascii images I think that can be useful, and at > >> the same time I am gaining in knowledge. > > > > You can use the live-sdk to create your own images. > > https://git.devuan.org/sdk/live-sdk > > > > -- > > ~ parazyd > > GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 > > > > Support i386? > I do not see that it makes to support it > > Greetings reiterated Yes, if you read the documentation, you can see how different architectures can be built. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help to create iso image
On Mon, 27 Mar 2017, Ismael L. Donis Garcia wrote: > - Original Message - > From: "Steve Litt" <sl...@troubleshooters.com> > To: <dng@lists.dyne.org> > Sent: Saturday, March 25, 2017 11:07 AM > Subject: Re: [DNG] Help to create iso image > > > > On Fri, 24 Mar 2017 14:59:57 -0500 > > "Ismael L. Donis Garcia" <sli...@natio.co.cu> wrote: > > > > > >> I want to create an iso of lxqt i386 for ascci with as little as > >> possible, but that is operative and pleasing to the eye at the same > >> time. > > > > For the pleasing to the eye part, you should consult golinux, who is a > > gifted designer. > > > > SteveT > > > > Steve Litt > > March 2017 featured book: Troubleshooting: Why Bother? > > http://www.troubleshooters.com/twb > > Thank you very much, I'll try to get in touch with him. > > I want to see if I can help in anything to devuan. > > And try to do something that is useful to others. > > As I see that nobody made ascii images I think that can be useful, and at > the same time I am gaining in knowledge. You can use the live-sdk to create your own images. https://git.devuan.org/sdk/live-sdk -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] getting surf from backports
On Tue, 14 Mar 2017, KatolaZ wrote: > On Tue, Mar 14, 2017 at 11:03:24AM +1100, Ozi Traveller wrote: > > Could we also get the later version of suckless-tools into jessie-backports > > for the later tabbed and demnu packages? > > > > Hi Ozi, > > I think it shouldn't bee too difficult to get an updated > suckless-tools package in Devuan. I will give a look at the current > one and see whether I can try to put together something useful :) > FWIW, you can backport the package from ascii :) -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] heads 0.0 is out!
On Sat, 04 Mar 2017, aitor_czr wrote: >Is there any link to the sources of the kernel? >Cheers, > Aitor. > Yes, on https://gogs.dyne.org/heads/linux-heads and on https://git.devuan.org/heads/linux-heads -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [ann] heads 0.0 is out!
On Tue, 28 Feb 2017, Hendrik Boom wrote: > On Tue, Feb 28, 2017 at 09:12:34PM +0100, parazyd wrote: > > heads 0.0 is out! > > It finally happened and it's not vaporware! > > It's out, it's not vaporware, it boots into a VM or bare hardware > from USB, but... > > What Is It? You continue looking at the website :p https://heads.dyne.org/ https://heads.dyne.org/about.html -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [ann] heads 0.0 is out!
heads 0.0 is out! It finally happened and it's not vaporware! heads 0.0 is a preview live CD of what heads is going to be about. This release is not intended to be used from a security point of view, but as a showcase and testing point of view. I am not even completely sure everything is torified, but hey, that's what testing is for, no? So please, download the ISO from the downloads link in the above navbar and abuse the hell out of it :) Throughout a certain period, bugs will be fixed within the build system, and patched releases will be released without announcement. So check regularly for 0.0.x releases on the downloads page... But first, read some notes on it all: Booting the ISO can be done with some virtualization like qemu or VirtualBox, or it can be dd-ed to a USB flash drive and booted on a laptop. It can be burned to optical media as well. The MATE desktop environment is not yet included in this release, only AwesomeWM is installed. You can install other environments easily by yourself. When booted, you will be presented with instructions on how to login, and start a graphical environment. Keep in mind the root password is shown only once and you will have to reboot if you lose access to it. https://heads.dyne.org/download/ -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [arm-sdk] fresh ARM builds
On Wed, 12 Oct 2016, parazyd wrote: > Hello fellow Devuaneers! > > I am proud to announce the RC1 (first release candidate) of the new ARM > image builds that are now using libdevuansdk as a common Devuan SDK > library: > > https://files.devuan.org/devuan_jessie_beta/testing/ > > The SHA256SUMS are signed with my GPG key (attached in this email). > > I would appreciate that the owners of the available boards test these > images and report back on how they are working, if there are any issues, > or wishes. > > Login credentials are root:toor > > Please report bugs, instability, etc. by opening an issue on git.do: > > https://git.devuan.org/sdk/arm-sdk > > Beaglebone Black owners, please email me in private if you wish to offer > help with testing, as I do not own the board myself. > > Currently offered images are armhf builds, with the exception of the > raspi3 image, which is arm64. The kernels are built with custom gcc > toolchains that can be retrieved at https://pub.parazyd.cf/mirror/ > > Currently with no hardening options, but that's a planned future option > > Enjoy :) > An image for Raspberry Pi 1 and Zero is up on files.devuan.org since today. Try it out if you have such a board :) https://files.devuan.org/devuan_jessie_beta/testing/devuan_jessie_1.0.0-beta2.rc1_armel_raspi1.img.xz -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] EterTICs GNU/Linux
On Fri, 04 Nov 2016, aitor_czr wrote: > As jaromil said in the IRC channel, there are packages of > linux-libre-4.7.2 in the repos: Perhaps you should note them the version is vulnerable to DirtyCOW. 4.7.10 is a version that has it fixed. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ 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 Mon, 24 Oct 2016, Florian Zieboll wrote: > On Mon, 24 Oct 2016 12:43:51 +0200 > parazyd <para...@dyne.org> wrote: > > > rpi-update works fine, yes. Keep in mind that the images themselves > > are filled up with latest git versions of firmware. > > Is there a repository I can point the rpi-update script at? If so, it > would only need to change the definition of $REPO_URI (and for the sake > of sustainability also $UPDATE_URI). In arm-sdk I clone the kernel [1], rpi-firmware [2], and also latest linux git firmware [3] References: [1] https://github.com/raspberrypi/linux.git [2] https://github.com/raspberrypi/firmware.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ 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 Mon, 24 Oct 2016, 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.) > > Libre Grüße, > > Florian > > [1] https://github.com/Hexxeh/rpi-update > [2] https://github.com/Hexxeh/rpi-firmware You can edit the fstab and remove 'noauto' from the /boot entry. I just put it that way there because the same was default in Raspbian. rpi-update works fine, yes. Keep in mind that the images themselves are filled up with latest git versions of firmware. -- ~ parazyd GPG: 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [arm-sdk] fresh ARM builds
Hello fellow Devuaneers! I am proud to announce the RC1 (first release candidate) of the new ARM image builds that are now using libdevuansdk as a common Devuan SDK library: https://files.devuan.org/devuan_jessie_beta/testing/ The SHA256SUMS are signed with my GPG key (attached in this email). I would appreciate that the owners of the available boards test these images and report back on how they are working, if there are any issues, or wishes. Login credentials are root:toor Please report bugs, instability, etc. by opening an issue on git.do: https://git.devuan.org/sdk/arm-sdk Beaglebone Black owners, please email me in private if you wish to offer help with testing, as I do not own the board myself. Currently offered images are armhf builds, with the exception of the raspi3 image, which is arm64. The kernels are built with custom gcc toolchains that can be retrieved at https://pub.parazyd.cf/mirror/ Currently with no hardening options, but that's a planned future option Enjoy :) -- ~ parazyd binZtEdQra3UV.bin Description: PGP Key 0x03337671FDE75BB6A85EC91FB876CB44FA1B0274. signature.asc Description: Digital signature ___ 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 Wed, 27 Jul 2016, Thomas Besser wrote: > Am 27.07.2016 um 09:58 schrieb parazyd: > > On Wed, 27 Jul 2016, Thomas Besser wrote: > >> Where can I find some starting stuff for Devuan on RPi? > > > > You can use the current master branch of arm-sdk[0] > > [...] > > > [0] https://git.devuan.org/devuan/arm-sdk > > I thought of some devuan images (alpha/beta) ;-) Oh, in that case, the beta image is already on all the mirrors: https://files.devuan.org/devuan_jessie_beta/devuan_jessie_1.0.0-beta_armhf_raspi2.img.xz This image will work on RPi2 and 3, and includes RPi3 firmware. You simply need to extract and dd the image to a card. Credentials to login are "root:toor" -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Caching binary .deb packages
On Mon, 06 Jun 2016, Lars Noodén wrote: > I've been messing around with building a live image and notice that it > looks like there are a lot of different mirrors getting called into > play. I was expecting the same mirrors to be used each time so I could > populate my local cache on the first try and then use that cache on > subsequent builds. Is there any efficient way to cache everything I > access on the first try? I'm using squid3 right now but should I be > using apt-cacher or apt-cacher-ng instead? > If you're consistently making the same image each time, why not create just a ready tarball you can extract each time you make an image? That way you save your time and put less load on package mirrors. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] use zram for /tmp - how?
For /tmp I would definitely use tmpfs. It's as simple as adding an entry to the fstab tmpfs /tmp tmpfs nodev,nosuid,size=2G 0 0 In this example, your /tmp will be 2 gigabytes big, but tmpfs will keep your /tmp in RAM, while not cutting off the entire 2GB of your system's RAM. It will only use as much as it needs. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan on RPi2
On Mon, 16 May 2016, info at smallinnovations.nl wrote: > I spended today some time to setup a Devuan version from my webradio on a > RPi2 and have 3 remarks. > > - had to add module snd_bcm2835 manually > - had to add alsa manually > - icecast2 asks for configuration parameters but does not save them (is > most likely not Devuan related but ask here to be sure) > > More people this experience? It's meant to be very minimal. If you want to autoload the kernel modules, it's as easy as putting them into /etc/modules Icecast on De*an does behave strange, even in my experience. In my case, I remember having to edit the initscript itself. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgp6fFsk8H6OU.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Unofficial Devuan live images
On Sat, 07 May 2016, fsmithred wrote: > If someone want to see what Devuan-Jessie beta looks like without > installing it, I made some live isos. I expect that there will eventually > be an official Devuan-Live, but this is not it. HTH. > > https://sourceforge.net/projects/refracta/files/unofficial_devuan_live/ > > [snip] Nice! Care to share any scripts or the workflow you have for creating such ISOs? -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpQLz5VIy8Z9.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Svante Signell wrote: > On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote: > > On Tue, 03 May 2016, Svante Signell wrote: > > > > > > > > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > > > > > > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > > > > > Because OpenRC has seen fit to intermix their init scripts > > > > with sysvinit's in /etc/init.d, I'd suggest that any files needed by > > > > OpenRC be kept somewhere besides /etc/init.d. > > > > > > > Hi Steve, > > > > > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst > > > was > > > used to to divert update-rc.d + invoke-rc.d files to not conflict with the > > > init- > > > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That > > > is > > > the solution used by file-rc. Currently systemd, sysvinit-core and openrc > > > use > > > the method of cooperating with the scripts update-rc.d and invoke-rc.d in > > > the > > > init-system-helpers package. Which is your preferred solution, we can go > > > either > > > way. > > invoke-rc.d and update-rc.d will NOT be used with OpenRc. > > In Debian openrc they are. > As I've stated at the beginning of this whole thread, debian-openrc is irrelevant and a bad way to solve the whole issue of using OpenRC properly, becase they keep using LSB initscripts... -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpb3NgSXd0KV.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Svante Signell wrote: > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote: > > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > > > > Because OpenRC has seen fit to intermix their init scripts > > with sysvinit's in /etc/init.d, I'd suggest that any files needed by > > OpenRC be kept somewhere besides /etc/init.d. > > > > Hi Steve, > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst was > used to to divert update-rc.d + invoke-rc.d files to not conflict with the > init- > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is > the solution used by file-rc. Currently systemd, sysvinit-core and openrc use > the method of cooperating with the scripts update-rc.d and invoke-rc.d in the > init-system-helpers package. Which is your preferred solution, we can go > either > way. invoke-rc.d and update-rc.d will NOT be used with OpenRc. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgppiqAXuDHjn.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Steve Litt wrote: > On Tue, 3 May 2016 10:06:07 -0400 (EDT) > Rob Owens <row...@ptd.net> wrote: > > > > I agree with putting each init in its own directory, but sysvinit > > should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit > > and by default /etc/init.d should be a link to /etc/sysvinit/init.d. > > The reason is that other init systems may expect to own /etc/init.d. > > For instance, openrc puts all its scripts in /etc/init.d (at least on > > Funtoo it does). > > I don't remember any other init wanting to use /etc/init.d, EXCEPT > OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and > the only one I know that wants to do that is systemd. > > I wouldn't change sysvinit's expected files one little bit. Everyone > assumes that /etc/init.d belongs exclusively to sysvinit. Any change to > sysvinit would require lots of testing, and who needs that headache? > > > > > Even though sysvinit is our default init system these days, we should > > not design Devuan such that it is difficult to change that in the > > future. So put sysvinit stuff in its own directory just like all the > > other inits. > > If you leave sysvinit's directories exactly as they exist now, > switching back and forth between sysvinit and runit is trivial. Same is > true of s6 and Epoch. > > Because OpenRC has seen fit to intermix their init scripts > with sysvinit's in /etc/init.d, I'd suggest that any files needed by > OpenRC be kept somewhere besides /etc/init.d. The problem with this is Debian itself. They insist on using LSB init scripts and in my opinion that they are somewhat different than what OpenRC wants. (For me at least) openrc initscripts are simpler, and also for respecting the openrc way(?) I wish to keep it in /etc/openrc. This way, with or without debhelper scripting OpenRC should work much more easily. The only thing then is that the package maintainers would have to include new initscripts in their packages, which might or might not be cumbersome for them. sysvinit should and will just stay where it already is. There is really no point in changing it's current configuration when other alternatives offer very easy ways to work around it. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpbfnv5FOub3.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Rob Owens wrote: > - Original Message - > > From: "KatolaZ" <kato...@freaknet.org> > > > But do we really need all that complication? Couldn't we just leave > > the initscript of each init system in a different directory and *tell > > the init system* where they are to be found? This will allow a much > > easier coexistence of different confs. > > > > Basically, everything related to sysvinit, stays in /etc/init.d, and > > sysvinit knows it has to look there. OpenRC stuff stays in > > /etc/openrc, and openrc knows it has to look there for its scripts. > > WFTinit stuff will stay in /etc/wtf, and WTFInit knows it has to look > > there for its stuff. We add the next-init-system, it will have its > > scripts in /etc/. > > I agree with putting each init in its own directory, but sysvinit > should not own /etc/init.d. sysvinit stuff should go in /etc/sysvinit > and by default /etc/init.d should be a link to /etc/sysvinit/init.d. > The reason is that other init systems may expect to own /etc/init.d. > For instance, openrc puts all its scripts in /etc/init.d (at least on > Funtoo it does). > > Even though sysvinit is our default init system these days, we should > not design Devuan such that it is difficult to change that in the > future. So put sysvinit stuff in its own directory just like all the > other inits. > This is unnecessary. In OpenRC you can easily specify $SYSCONFDIR and set it to /etc/openrc. Then all will be found inside, and the system will already know what to do, without symlinking. -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgp8gAxom6MNU.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, Simon Hobson wrote: > Jaromil <jaro...@dyne.org> wrote: > > >> Instead of an openRC effort at this point, I'd rather see a hook > >> for apt-get / aptitude / etc, to move all files specific to init > >> systems not being used to their own file hierarchies, eg. > >> > >> /var/cache/init-systems > >>/sysvinit > >> /etc > >> /lib > >> /usr > >>/openrc > >> /etc > >> /lib > >> /usr > >>/systemd > >> /etc > >> /lib > >> /usr > > > This is an important suggestion, which parazyd himself was evaluating > > yesterday, noting that among the errors made in the previous openrc > > packages was this one: put the files of each init system in the same > > /etc/init.d directory, basically making them overlap. > > > > I agree we should adopt the policy you are proposing in Devuan. > > How does that work in terms of getting the right files into place ? Is it a > case of the switching process will copy the files into /etc and so on ? Or > will they be symlinked, or what ? And possibly more important, what's the > process for removing them when switching to another init ? And what about > having two systems installed for those who want to try one but leave the > other selectable at boot time (for if it doesn't work out ?) > I'm thinking back to the "debate" over /bin and /usr/bin and the discussions > related to what needs to be mounted early during boot - /var isn't typically > mounted until relatively late. > > From that basis, would it be better to perhaps put openrc scripts in > /etc/init-orc or something like that ? > /var/cache/init-systems ?? Yes, I know it's just an example, but is a very wrong one. All OpenRC specific files/dirs like init.d, conf.d, runlevels and such simply go to /etc/openrc/ , much like systemd with /etc/systemd. It is really the correct way to do it. Also, if one switches to OpenRC, you should forget about helper scripts like update-rc.d. If one switches to OpenRC from sysvinit, the install script would just have to look for the enabled initscripts and their runlevels, and enable them accordingly with OpenRC. Provided the initscripts are included in the packages already installed. On that note, Gentoo's package repositories might be a valuable resource. On what could/could be removed, IMHO the old sysvinit scripts can stick around because they will not overlap with OpenRC's scripts. The only thing that comes to mind is the inittab and how it will be handled? Perhaps just a symlink to /etc/openrc/inittab ... -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpTZ_udPcP6E.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Tue, 03 May 2016, poitr pogo wrote: > I vote for init to be default for at least few years. > Devuan might consider switching to something else few years after > wheezy lts will be dead. > > Meantime, all other init systems should be optional in Devuan. > Then there is just enough time to make it work properly :) -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpC7gbnp3ThE.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Devuan
On Mon, 02 May 2016, Hendrik Boom wrote: > Is there a summary of some sort explaining the various init systems, > how they're put together, how they work, and especially the salient > points on which they differ? Perhaps this as a short intro: https://wiki.gentoo.org/wiki/Comparison_of_init_systems -- ~ parazyd 0333 7671 FDE7 5BB6 A85E C91F B876 CB44 FA1B 0274 pgpGHFS4lCa45.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] debootstrap requires key
On Mon, 25 Apr 2016, Haines Brown wrote: > On Mon, Apr 25, 2016 at 05:47:15PM +0200, parazyd wrote: > > On Mon, 25 Apr 2016, Haines Brown wrote: > > > > Perhaps my problem was that I unpacked the devuan.debian.tar.gz archive > > > on the target /mnt/debinist/usr/share. If instead I run > > > > > > # dpkg -i debootstrap_1.0.75-1+devuan1_all.deb > > > > > > I fear it will overwrite the debootstrap on my current Wheezy Debian > > > system and break it. > > > > The debootstrap from devuan is safe to install. It differs only in > > having a few bugfixes. Besides, you can always grab the package from > > wheezy and overwrite. > > Again, please excuse my ignorance. You appear to say that I can use dpkg > to install the dpkg -i debootstrap_1.0.75-1+devuan1_all.deb on my > running Wheezy system, for it is essentially the same. But when I do > that and run: > > # debootstrap -no-check-gpg jessie /mnt/debinst/ \ > http://packages.devuan.org/merged > E: No such script: http://packages.devuan.org/merged > > > Anyway, sorry if there is too much 'tech talk'. Try looking at this > > forum thread: > > http://www.linuxquestions.org/questions/debian-26/how-to-install-debian-using-debootstrap-4175465295/ > > Yes, thanks. What confused me was that when I did cross installation in > years past, there were no stages to worry about. But the immediate > problem is that I can't even get started with the above command. > "-no-check-gpg" should be "--no-check-gpg" What if you do this? # debootstrap --no-check-gpg --foreign --arch [architecture] jessie \ /mnt/debinst http://packages.devuan.org/merged -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgpGhUhylX_f8.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] debootstrap requires key
On Mon, 25 Apr 2016, Haines Brown wrote: > I apologize for being so slow, but problems abound. I decided to try the > devuan installation with the installer ISO on a key. I used the > devuan-jessie-i386-alpha4-netboot.iso. However, when it came time to > download installation components from the devuan archive, it failed: > "Bad archive mirror". > > The archive it tried was us.mirror.devuan.org. Shouldn't it be > us.mirror.devuan.org? When I used debootstrap to produce the broken base > system, it created a sources.list with the entry: deb > http://debootstrap.invalid/ jessie main. > > As for your script, I remain lost (I'm not a programmer, but a social > scientist). I don't know what the variable "device-name" refers > to. Perhaps to the /dev/sda1 to which I'm trying to install devuan. I > assume that second and third stage refer to phases in the installation > process, but I have no idea what they are. If you are simply suggesting > I rerun debootstrap several times, I actually did it at least twice, and > still get the message that seems to imply my libc version is wrong. > > Perhaps my problem was that I unpacked the devuan.debian.tar.gz archive > on the target /mnt/debinist/usr/share. If instead I run > > # dpkg -i debootstrap_1.0.75-1+devuan1_all.deb > > I fear it will overwrite the debootstrap on my current Wheezy Debian > system and break it. The debootstrap from devuan is safe to install. It differs only in having a few bugfixes. Besides, you can always grab the package from wheezy and overwrite. Anyway, sorry if there is too much 'tech talk'. Try looking at this forum thread: http://www.linuxquestions.org/questions/debian-26/how-to-install-debian-using-debootstrap-4175465295/ A debootstrap system install has three stages, which you must complete to get a working system. It's not running debootstrap multiple times, but more like running debootstrap's flow(?) Perhaps it helps more :) -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgpUOa1zhUHOa.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] debootstrap requires key
On Mon, 25 Apr 2016, Haines Brown wrote: > On Sun, Apr 24, 2016 at 09:37:24PM +0200, parazyd wrote: > > > Yes, debootstrap works on any system. Note that if you wish to bootstrap > > devuan systems, use devuan's debootstrap (which was fixed): > > https://packages.devuan.org/devuan/pool/main/d/debootstrap/ > > Yes, I unarchived debootstrap_1.0.75-1+devuan1.debian.tar.gz in the > target disk (/mnt/debinst/usr/share) and ran: > > # debootstrap --no-check-gpg jessie /mnt/debinst \ > http://packages.devuan.org/merged > > It installed a base system on the target disk mounted on > /mnt/debinst. But that base system is apparently broken because of a > version inconsistency: > > W: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version 'GLIB_2.17' not > found (required by /lib-i386-linux-gnu/libmount.so.1) > > If you are implying the version clash is because I used the debian > rather than the devuan debootstrap, that is not the case. I need to > correct this problem in order to chroot into the new system to configure > and develop it. > > > Also, for next steps, I'd recommend you to see how the ARM SDK works, > > particularly the devuan profile: > > https://git.devuan.org/devuan/arm-sdk/blob/master/arm/profiles/common-devuan > > This is a program you wrote. Much appreciated, but I have no idea what > it is for or how to use it. > Once you do debootstrap once, you also need to do the second and the third stage, respectively, to get a working system. This is why I linked to "common-devuan" because in there you can see what you have to do. Go to the bottom, and look at the for-loop. These are the complete steps on how to get a fully bootable system. -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgp7oa4x9i2K2.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] debootstrap requires key
On Sun, 24 Apr 2016, Haines Brown wrote: > On Sun, Apr 24, 2016 at 03:41:51PM +0100, dev1fanboy wrote: > > > When you say installed debootstrap on a new disk, you mean the host > > OS? What architecture is the host and the 'target' disk, are they > > different? > > Sorry I was not clearer. I meant debootstrap installed a base system on > a new disk. > ># debootstrap --no-check-gpg jessie /mnt/debinst \ > https://packages.devuan.org/devuan > > The host, my currently running machine, runs debootstrap, targetting a > new partitioned disk mounted on /mnt/debinst. I'm assuming debootstrap > can be run anywhere, and it installs a base system wherever it is told > to do it. Years ago I did cross installations, but the process has > gotten a lot more complicated. Yes, debootstrap works on any system. Note that if you wish to bootstrap devuan systems, use devuan's debootstrap (which was fixed): https://packages.devuan.org/devuan/pool/main/d/debootstrap/ Also, for next steps, I'd recommend you to see how the ARM SDK works, particularly the devuan profile: https://git.devuan.org/devuan/arm-sdk/blob/master/arm/profiles/common-devuan -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgpevJeYAmW3y.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] debootstrap requires key
On Sat, 23 Apr 2016, Haines Brown wrote: > This has come up before, but I still don't know the basic > procedure. I've installed debootstrap on a new disk and run: > > # debootstrap --arch amd64 jessie /mnt/debinst \ > https://packages.devuan.org/devuan > > I: Retrieving Release > I: Retrieving Release.gpg > I: Checking Release signature > E: Release signed by unknown key (key id 94532124541922FB) > > No change when I downloaded and ran > > # dpkg -i devuan-keyring_2015.05.05_all.deb > > Do I have the right keyring? Was the alpha4 release date > c. 2015.05.05? > > In simple step by step terms, what do I do? > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Maybe try signing the key locally: # gpg --lsign-key 94532124541922FB and/or add it to apt by doing: # gpg --export -a 94532124541922FB | apt-key add - -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgpxctDTl1Eof.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Gcc issue?
On Thu, 21 Apr 2016, Steven W. Scott wrote: >Just curious, anyone else getting segfaults after compiling with gcc -O3 >optimization flag on alpha 4? Same system, same code, same flags work ok >on Wheezy. If I back down to -O2 no problems. > >I'm blaming gcc, but I was interested if anyone else had a similar >experience or insight as to what might be the issue. Do you actually understand how optimization works? The bigger the level, the more unsafe code you get, like you just got segfaults. Depending on the program, one will take some max. level of optimization, but any higher and it will break, like yours did. Note how many more warnings you get on compilation as you get higher in optimization level. You could blame GCC, because optimization is a feature of GCC, but I'd still keep calm and just compile with -O2, which is basically a standard these days. -- ~ parazyd 6CB4 6C63 641D B1F1 F811 5B3A BB5E 2E35 B92E 373E pgp2djBHrqMXI.pgp Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Raspberry Pi 2 image
On Mon, 11 Apr 2016, aitor_czr wrote: > To build your own images, consult the README file inside the arm > directory. > >I tried running sdk-init, but it's not recognized. > >Salaam alekum, > > Aitor. You didn't read it well in that case... The command you would run is `init-arm RaspberryPi2` - which will then present you with further instructions... signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Raspberry Pi 2 image
On Sun, 10 Apr 2016, Steve Litt wrote: > On Sun, 10 Apr 2016 17:44:16 +0200 > parazyd <para...@dyne.org> wrote: > > > > The raspi-config utility still needs some polishing to work properly > > on Devuan, so I would like to propose anyone interested in helping > > fix it to clone my devuan-sdk repository, and inside, in the > > "arm/extra/rpi-conf" directory, you can find "raspi-config". > > Are there documents to show how to directly edit config files to achive > the ends of raspi-config? There is only their github repository, which holds not so enough documentation: https://github.com/RPi-Distro/raspi-config It was made with Raspbian Jessie in mind, so it (sometimes heavily) depends on systemd. signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Raspberry Pi 2 image
On Sun, 10 Apr 2016, KatolaZ wrote: > > The raspi-config utility still needs some polishing to work properly on > > Devuan, so I would like to propose anyone interested in helping fix it > > to clone my devuan-sdk repository, and inside, in the "arm/extra/rpi-conf" > > directory, you can find "raspi-config". Feel free to hack on it, and if > > you fix things, please make a pull request so I can review it. > > https://github.com/parazyd/devuan-sdk > > > > To build your own images, consult the README file inside the arm > > directory. > > > > As for the Raspberry Pi 1 and Zero - Devuan's packages should be > > compiled for armv6. If it's a possibility, I would recommend (re)building > > all armhf packages with armv6 in mind. This way, packages would work > > just as fine on *all* Raspberry Pis and other embedded devices. > > > > As I said a couple of weeks ago, I have already experimented with a > custom toolchain for armv6+VFP2, and it works (I was able to > cross-compile a relatively large custom software toolbox in C which > runs smoothly on the rpi0). I have also built a basic system using > LFS, but I did not manage to make it boot, since the boot process in > the pi is a clusterfuck, as parazyd correctly pointed out on IRC. Feel free to see the linked github repository to see how booting is solved for Raspberry Pi 2. The Raspi1/0 will have to be built with a different kernel, and toolchain for that matter. Otherwise, things should stay relatively the same as in the Rpi2 script. > Now the thing should be integrated in devuan-sdk, the main problem > being that we should recompile all the needed packages and use another > target name, since armhf already refers to armv7 and armel refers to > arm with soft FPU. armv6+VFP2 is a hybrid of the two, indeed... Without putting much thought in it, maybe the naming scheme could be arm6hf/arm7hf or armhf6/armhf7? I am really not sure how many existing things it would break though... signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Raspberry Pi 2 image
Hi dng! Devuan Raspberry Pi 2 images are done and ready :) The image I would like people to test can be found here: https://parazyd.dyne.org/devuan-jessie-alpha4-armhf-rpi2.img.xz along with the sha256sum: https://parazyd.dyne.org/devuan-jessie-alpha4-armhf-rpi2.img.xz.sha To use, simply extract and dd to a SD card. SSH will start on first boot, you can login as root with credentials "root:porcoddio" The raspi-config utility still needs some polishing to work properly on Devuan, so I would like to propose anyone interested in helping fix it to clone my devuan-sdk repository, and inside, in the "arm/extra/rpi-conf" directory, you can find "raspi-config". Feel free to hack on it, and if you fix things, please make a pull request so I can review it. https://github.com/parazyd/devuan-sdk To build your own images, consult the README file inside the arm directory. As for the Raspberry Pi 1 and Zero - Devuan's packages should be compiled for armv6. If it's a possibility, I would recommend (re)building all armhf packages with armv6 in mind. This way, packages would work just as fine on *all* Raspberry Pis and other embedded devices. Cheers! ~ parazyd signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] files.devuan.org not working
On Wed, 30 Mar 2016, Jaromil wrote: > On Tue, 29 Mar 2016, Linux O'Beardly wrote: > > >Do we know when this will be fixed? It's really hard to spread the gospel > >of Devuan if my disciples can't get to the source of enlightenment. > > yes its a matter of days > > let's encrypt doesn't emits more than 5 certificates for vhosts of the > same domain each week... For what it's worth, it is now upped to 30 certs. signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
