Re: [DNG] Trying (again) to compile simple-netaid (was, netman)
Hi Didier, El 09/02/16 a las 18:18, Didier Kryn escribió: Please Aitor, could you solve this issue with the subject of your emails. I don't know what mail client you are using, but I think you should change if it does only allow you a constant subject for all emails. Didier I sent it twice cirectubng the subject. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Trying (again) to compile simple-netaid (was, netman)
Hi Hendrik, El 09/02/16 a las 21:00, Hendrik Boom escribió: Are those the required packages for building it? or for running it? -- hendrik For building it. The required packages for running it are: netman-backend -> |libc-bin |netman-frontend -> |netman-backend, libgtk2.0-0, libatk1.0-0, libgdk-pixbuf2.0-0, libpango-1.0-0, libx11-6 Cheers, Aitor. | ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Trying (again) to compile simple-netaid (was, netman)
Hi Svante, El 09/02/16 a las 23:34, Svante Signell escribió: On Tue, 2016-02-09 at 12:44 -0500, Hendrik Boom wrote: >On Tue, Feb 09, 2016 at 01:24:35PM +0100, aitor_czr wrote: > >Hi Enzo, > > > >Here you are a list of the required packages (i tested it within a > >minimal chroot jail): > > > >build-essential > >libgtk2.0-dev > >fp-units-gfx-2.6.4 > >lazarus > >lazarus-ide-gtk2 > >lcl-nogui-1.2.4 > >lcl-utils-1.2.4 > >lcl-units-1.2.4 > >Are those the required packages for building it? or for running it? Build most probably, for the front-end package. And these dependencies should be in the debian/control file for that package. I don't think an INSTALL file is mandatory. See here: https://git.devuan.org/aitor_czr/netman/tree/master/debian The netman-gui.postinst file is not updated. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Trying (again) to compile simple-netaid (was, netman)
El 10/02/16 a las 09:01, aitor_czr escribió: Hi Didier, El 09/02/16 a las 18:18, Didier Kryn escribió: Please Aitor, could you solve this issue with the subject of your emails. I don't know what mail client you are using, but I think you should change if it does only allow you a constant subject for all emails. Didier I sent it twice cirectubng [**] the subject. Aitor. [**] correcting ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help me understand what Daniel Reurich is asking?
Hi, I am trying to use git buildpackage with the following results: a) with an orig.tar.gz archive in the parent directory of the sources I get: ~/simple-netaid-0.1.1$ git buildpackage dpkg-buildpackage -rfakeroot -D -us -uc -i -I dpkg-buildpackage: source package simple-netaid dpkg-buildpackage: source version 0.1.1-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Edward dpkg-source -i -I --before-build simple-netaid-0.1.1 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean make[1]: Entering directory '/home/edbarx/simple-netaid-0.1.1' make -C backend_src clean make[2]: Entering directory '/home/edbarx/simple-netaid-0.1.1/backend_src' rm -f obj/backend.o obj/caller.o obj/core_functions.o obj/file_functions.o obj/essid_encoder.o obj/automated_scanner.o bin/backend make[2]: Leaving directory '/home/edbarx/simple-netaid-0.1.1/backend_src' rm -f lib/*/*.* rm -f backend simple-netaid make[1]: Leaving directory '/home/edbarx/simple-netaid-0.1.1' dh_clean dpkg-source -i -I -b simple-netaid-0.1.1 dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision dpkg-buildpackage: error: dpkg-source -i -I -b simple-netaid-0.1.1 gave error exit status 255 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed gbp:error: 'debuild -i -I' failed: it exited with 29 b) without a .orig.tar.gz archive in the parent directory I get: ~/simple-netaid-0.1.1$ git buildpackage This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory; (expected one of simple-netaid_0.1.1.orig.tar.gz, simple-netaid_0.1.1.orig.tar.bz2, simple-netaid_0.1.1.orig.tar.lzma, simple-netaid_0.1.1.orig.tar.xz or simple-netaid-0.1.1.orig) continue anyway? (y/n) y dpkg-buildpackage -rfakeroot -D -us -uc -i -I dpkg-buildpackage: source package simple-netaid dpkg-buildpackage: source version 0.1.1-1 dpkg-buildpackage: source distribution unstable dpkg-buildpackage: source changed by Edward dpkg-source -i -I --before-build simple-netaid-0.1.1 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean dh_testdir dh_auto_clean make[1]: Entering directory '/home/edbarx/simple-netaid-0.1.1' make -C backend_src clean make[2]: Entering directory '/home/edbarx/simple-netaid-0.1.1/backend_src' rm -f obj/backend.o obj/caller.o obj/core_functions.o obj/file_functions.o obj/essid_encoder.o obj/automated_scanner.o bin/backend make[2]: Leaving directory '/home/edbarx/simple-netaid-0.1.1/backend_src' rm -f lib/*/*.* rm -f backend simple-netaid make[1]: Leaving directory '/home/edbarx/simple-netaid-0.1.1' dh_clean dpkg-source -i -I -b simple-netaid-0.1.1 dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision dpkg-buildpackage: error: dpkg-source -i -I -b simple-netaid-0.1.1 gave error exit status 255 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed gbp:error: 'debuild -i -I' failed: it exited with 29 What is the problem? It seems to having to do with a revision. Thanks for all your help. Edward On 10/02/2016, Daniel Reurich wrote: > On 10/02/16 19:53, Edward Bartolo wrote: >> Hi, >> >> This is an email sent to me by Daniel Reurich >> >> Begin Email Quote: >> >> Hi Edward, >> >> I've forked and tried to build your project: >> https://git.devuan.org/net/simple-netaid >> >> It's failed to build the sources for a very basic reason: >> >> You need to decide if this is primarily a native Devuan/Debian >> project or an upstream project being packaged for Devuan. Either is >> fine, but currently the packaging appears to be a half way between. >> IE; you have a patch series that indicates a quilt package but no >> upstream branch, tags, tarball or pristine-tar branch of the original >> unde[bi|vu]anised sources. >> >> I suggest either merge the patches into the source, and change the >> source format to either "3.0 (native)" or "3.0 (git)" (we support >> gitsrc in our build system unlike debian), or alternatively produce >> either a separate upstream branch of the clean sources, or a pristine >> tar branch (pain in the arse - I don't recommend this) or even just a >> plain old tar ball. >> >> I guess the choice comes down to your primary target. If you >> developing this primarily for Devuan then native or gitsrc formats are >> fine. I'd vote for gitsrc but I'm biased due to having added the >> support for that format to our build system and I don't understand why >> you'd want tarball based srcs for packages developed and built from >> git. >> >> I can do the conversion to gitsrc for this pretty quickly and >> painlessly and get this building in Devuan. >> >> Let me know. >> >> End Email Quote: >> >> >> If I am understanding well, the state of my sources is in a
[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
[DNG] vdev packaging effort ( was: state of what's working, for modern desktop usage)
El 10/02/16 a las 13:00, shraptor escribió: I think Aitor wrote a while ago about creating a vdev package? Aitor could you give an update on that effort? best regards Scooby Hups! :) ___ 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 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. An installable package of vdev in Devuan beta will definitely leverage its testing base. Thanks for working on this, is quite important. ciao ___ 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)
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. 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. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help me understand what Daniel Reurich is asking?
Edward Bartolo writes: > This is an email sent to me by Daniel Reurich [...] > I've forked and tried to build your project: > https://git.devuan.org/net/simple-netaid > > It's failed to build the sources for a very basic reason: > > You need to decide if this is primarily a native Devuan/Debian > project or an upstream project being packaged for Devuan. [...] > If I am understanding well, the state of my sources is in a hybrid > state between Debianized and Non-Debianized. > > Can anyone have some patience to explain to me what commands, I assume > git commands, I have to run to do what Daniel (Centurion_Dan) is > asking? That's what I also tried to tell you a couple of time: You can just build a native package by integrating whatever separate patches you might have and getting rid of the quilt-stuff altogether. In fact, the various patches I sent to this list were supposed to enable exactly that. They worked for me but you always claimed they would end up corrupting or breaking this or that without ever supplying enough information to try to track down the issue, then, chose to sidestep it in some way. I'm (time permitting) willing to help with sorting this out again, however, with the modus operandi described above, this won't work. ___ 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)
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. ___ 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 Wed, 2/10/16, Jaromil wrote: Subject: Re: [DNG] vdev packaging effort ( was: state of what's working for modern desktop usage) To: dng@lists.dyne.org Date: Wednesday, February 10, 2016, 8:09 AM 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. An installable package of vdev in Devuan beta will definitely leverage its testing base. Thanks for working on this, is quite important. ciao It would be helpful for those of us on the other side of the planet to know when this will be happening in Amsterdam time so we can do the necessary conversion and set the time aside. Thanks. golinux ___ 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)
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 calls a dispatcher function which determines which applet to call (there is one applet per supported application) from the name of the link. And there is no applet named 'dash' in Busybox. But Busybox knows 'ash' and 'sh', which point to the same applet. 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. Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wifi device names: was systemd is haunting me
On Mon, 01 Feb 2016 17:08:17 +
Rainer Weikusat wrote:
> Steve Litt writes:
> > On Sun, 31 Jan 2016 18:20:12 -0500
> > Steve Litt wrote:
>
> [...]
>
> > ===
> > #!/bin/sh
> > lineno=${1:-1}
> >
> > fn=`mktemp`
> >
> > ip -o link | \
> > cut -d ' ' -f2 | \
> > grep ^w | \
> > tr -d : > $fn
> >
> > maxdev=`wc -l $fn | cut -d ' ' -f 1`
> > if test $maxdev -lt $lineno; then
> >echo =max$maxdev
> > else
> > head $fn -n $lineno | \
> > tail -n 1
> > fi
> > rm $fn
> > ===
>
> [...]
>
> > There are probably better ways to write this script, but I think the
> > way I have it here exhibits the behavior I'd like.
>
> 'Better' is often very much a matter of opinion but here's one which
> doesn't need a temporary file:
>
> -
> #!/bin/sh
> want=${1:-1}
> got=0
>
> for dev in `ip -o link | sed -n 's/[^:]*: *\(w[^:]*\).*/\1/p'`;
> do
> got=`expr $got + 1`
>
> test $got -eq $want && {
> echo $dev
> exit 0
> }
> done
>
> echo =max$got
Hi Rainer,
At the start of this thread, I had put my contribution into the Public
Domain. Then you and I started incrementally improving it, so it's
pretty much a mashup of both our works.
I'd like to use it in a package of shellscripts I'll be releasing as
Free Software. For this particular shellscript written by both of us,
would it be OK with you if we licensed it under the Expat license?
http://directory.fsf.org/wiki/License:Expat
The preceding is basically a dup of the MIT license and some of the
later BSD licenses, but by calling it "Expat" we rule out various
versions and the like.
Is it OK with you to license it Expat? Is it OK with you if both our
names appear on the Copyright line? If so, is the exact correct
spelling of your name "Rainer Weikusat"?
Did anyone else substantially contribute in creating the shellscript to
derive the Wifi device name on systems with the new "predictable"
device names? If so, same questions to you.
Thanks,
SteveT
Steve Litt
February 2016 featured book: The Key to Everyday Excellence
http://www.troubleshooters.com/key
___
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)
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. ___ 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 Wed, 10 Feb 2016 15:11:16 +0100 Didier Kryn wrote: > 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. > > 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. > > Didier Didier, If you ever come to Orlando, Florida, USA, could you please give a presentation on Busybox and its use with initramfs systems at our local LUG, GoLUG? Your info is tremendously geeky and tremendously useful. Thanks, SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wifi device names: was systemd is haunting me
Steve Litt writes: > Rainer Weikusat wrote: [shell scripts] > At the start of this thread, I had put my contribution into the Public > Domain. Then you and I started incrementally improving it, so it's > pretty much a mashup of both our works. [...] > Is it OK with you to license it Expat? Is it OK with you if both our > names appear on the Copyright line? If so, is the exact correct > spelling of your name "Rainer Weikusat"? How 'legal' do you want this to be? My work contract has a clause which states that even if I dream of code/ something else which might be useful, the rights rest with my employer. OTOH, my employer doesn't care about this and neither do I: If I just post the code without adding something like "this is copyrighted by ... and quoted here for educational purposes", you (or anyone else) can assume "public domain". Spelling is correct. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wifi device names: was systemd is haunting me
> How 'legal' do you want this to be? My work contract has a clause which > states that even if I dream of code/ something else which might be > useful, the rights rest with my employer. That's insane and surely it's legally unenforceable, and certainly if they don't pay you for the time spent dreaming code D: -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Help me understand what Daniel Reurich is asking?
Hi Edward, On 02/10/2016 08:09 AM, Edward Bartolo wrote: Hi, This is an email sent to me by Daniel Reurich Begin Email Quote: Hi Edward, I've forked and tried to build your project: https://git.devuan.org/net/simple-netaid It's failed to build the sources for a very basic reason: You need to decide if this is primarily a native Devuan/Debian project or an upstream project being packaged for Devuan. Either is fine, but currently the packaging appears to be a half way between. IE; you have a patch series that indicates a quilt package but no upstream branch, tags, tarball or pristine-tar branch of the original unde[bi|vu]anised sources. I suggest either merge the patches into the source, and change the source format to either "3.0 (native)" or "3.0 (git)" (we support gitsrc in our build system unlike debian), or alternatively produce either a separate upstream branch of the clean sources, or a pristine tar branch (pain in the arse - I don't recommend this) or even just a plain old tar ball. I guess the choice comes down to your primary target. If you developing this primarily for Devuan then native or gitsrc formats are fine. I'd vote for gitsrc but I'm biased due to having added the support for that format to our build system and I don't understand why you'd want tarball based srcs for packages developed and built from git. I can do the conversion to gitsrc for this pretty quickly and painlessly and get this building in Devuan. Let me know. End Email Quote: If I am understanding well, the state of my sources is in a hybrid state between Debianized and Non-Debianized. Can anyone have some patience to explain to me what commands, I assume git commands, I have to run to do what Daniel (Centurion_Dan) is asking? My textual source files are already up to date, so what will patching actually do? Should I edit debian/source/format to contain: 3.0 (native) instead of 3.0 (quilt) Thanks, Edward. $ git clone https://git.devuan.org/edbarx/netman.git $ mv netman simple-netaid $ tar -c simple-netaid | bzip2 > simple-netaid_0.1.1.orig.tar.bz2 $ pristine-tar commit ../simple-netaid_0.1.1.orig.tar.bz2 tags/0.1.1 $ git-buildpackage -tc --git-export-dir="../build-area" --git-pristine-tar --git-tag --git-ignore-branch You can also create a hidden config .gbp file instead of using arguments in the command line. HTH. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Wifi device names: was systemd is haunting me
On Thu, 11 Feb 2016 12:10:23 +1300 Daniel Reurich wrote: > > How 'legal' do you want this to be? My work contract has a clause > > which states that even if I dream of code/ something else which > > might be useful, the rights rest with my employer. > > That's insane and surely it's legally unenforceable, and certainly if > they don't pay you for the time spent dreaming code > > D: Hi Daniel, You'd be hugely surprised at how literally some states in the US interpret contracts. I live in (anti-employee) Florida, and a friend of mine here in Florida was advised by his lawyer to not work for Linux for the next 6 months because his former employer had a 6 month anti-compete on any Linux work. His lawyer said he'd likely lose the case if he did Linux and his old employer sued. Meanwhile, in California, that kind of non-compete is illegal. This often becomes a problem in Free Software, as former employers covet Free Software rights on software written by their employees on the employee's own time and with the employee's own computer. This is the reason a lot of Free Software authors assign all rights to the FSF. I don't do that because I've been self-employed since 1982. SteveT Steve Litt February 2016 featured book: The Key to Everyday Excellence http://www.troubleshooters.com/key ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Help me understand what Daniel Reurich is asking?
Sorry, some lines were missing: $ git clonehttps://git.devuan.org/edbarx/netman.git $ mv netman simple-netaid $ tar -c simple-netaid | bzip2 > simple-netaid_0.1.1.orig.tar.bz2 $ cd simple-netaid $ git tag -a 0.1.1 -m 'my_dear_netbarx_sniff' $ pristine-tar commit ../simple-netaid_0.1.1.orig.tar.bz2 tags/0.1.1 $ git-buildpackage -tc --git-export-dir="../build-area" --git-pristine-tar --git-tag --git-ignore-branch You can also create a hidden config .gbp file instead of using arguments in the command line. HTH. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help me understand what Daniel Reurich is asking?
Hi Aitor et al, This is what I got: edbarx@edbarx-pc:~$ tar -c simple-netaid | bzip2 > simple-netaid_0.1.1.orig.tar.bz2 edbarx@edbarx-pc:~$ cd simple-netaid edbarx@edbarx-pc:~/simple-netaid$ git taf -a 0.1.1 -m "Tagging simple-netaid version number 0.1.1" git: 'taf' is not a git command. See 'git --help'. Did you mean this? tag edbarx@edbarx-pc:~/simple-netaid$ git tag -a 0.1.1 -m "Tagging simple-netaid version number 0.1.1" edbarx@edbarx-pc:~/simple-netaid$ pristine-tar commit ../simple-netaid_0.1.1.orig.tar.bz2 tags/0.1.1 pristine-tar: committed simple-netaid_0.1.1.orig.tar.bz2.delta to branch pristine-tar edbarx@edbarx-pc:~/simple-netaid$ mkdir ../build-area edbarx@edbarx-pc:~/simple-netaid$ git-buildpackage -tc --git-export-dir="../build-area" --git-pristine-tar --git-tag --git-ignore-branch gbp:info: Exporting 'HEAD' to '/home/edbarx/build-area/simple-netaid-tmp' gbp:info: Moving '/home/edbarx/build-area/simple-netaid-tmp' to '/home/edbarx/build-area/simple-netaid-1' This package has a Debian revision number but there does not seem to be an appropriate original tar file or .orig directory in the parent directory; (expected one of simple-netaid_0.1.1.orig.tar.gz, simple-netaid_0.1.1.orig.tar.bz2, simple-netaid_0.1.1.orig.tar.lzma, simple-netaid_0.1.1.orig.tar.xz or simple-netaid-1.orig) continue anyway? (y/n) n gbp:error: 'debuild -i -I -tc' failed: it exited with 1 Processing stopped there. I cannot understand the error as an orig.tar.bz2 file has been supplied. Edward On 11/02/2016, aitor_czr wrote: > Sorry, some lines were missing: > > $ git clonehttps://git.devuan.org/edbarx/netman.git > > $ mv netman simple-netaid > > $ tar -c simple-netaid | bzip2 > simple-netaid_0.1.1.orig.tar.bz2 > > $ cd simple-netaid > > $ git tag -a 0.1.1 -m 'my_dear_netbarx_sniff' > > $ pristine-tar commit ../simple-netaid_0.1.1.orig.tar.bz2 tags/0.1.1 > > $ git-buildpackage -tc --git-export-dir="../build-area" --git-pristine-tar > --git-tag --git-ignore-branch > > > You can also create a hidden config .gbp file instead of using arguments > in the command line. > > HTH. > > Aitor. > > > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help me understand what Daniel Reurich is asking?
On 02/11/2016 08:21 AM, Edward Bartolo wrote: $ git taf -a 0.1.1 -m "Tagging simple-netaid version number 0.1.1" $ git tag [...] Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Help me understand what Daniel Reurich is asking?
Hi, I repeated the git tag command and it was successfully run. However, git-buildpackage complained that there is no simple-netaid_0.1.1.orig.tar.bz2 file in the sources parent directory. As there is actually a simple-netaid_0.1.1.orig.tar.bz2 file, I am perplexed. Edward On 11/02/2016, aitor_czr wrote: > > On 02/11/2016 08:21 AM, Edward Bartolo wrote: >> $ git taf -a 0.1.1 -m "Tagging >> simple-netaid version number 0.1.1" > > $ git tag [...] > > Aitor. > ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
