Re: [DNG] Packaging Vdev

[aitor_czr]

Hi again,

On 03/27/2016 11:44 AM, aitor_czr wrote:


On 03/26/2016 02:53 PM, aitor_czr wrote:


On 03/26/2016 02:28 PM, aitor_czr wrote:

Here you are an experimental packaging of VDEV for amd64 and i386:

http://gnuinos.org/unsystemd/

The repository is:

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

You can import the public key doing:

curl http://gnuinos.org/unsystemd/aitor_pk.asc | apt-key add -

Cheers,

   Aitor.


I have to add the vdev word in the description of libudev-compat. It 
doesn't appear filtering with vdev in synaptic.


  Aitor.


If you download vdev-example.deb, all the paths located in 
/usr/etc/vdev/vdevd.conf must be changed from /usr/local to /usr.


I also should add the following line to vdevd in debian/control.

Provides: udev

More suggestions?

Cheers,

  Aitor. 


Building the example of vdev, folders like "/usr/etc/acls" and 
"/usr/etc/initramfs" evaporate. Is something missing in the Makefile?


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

Re: [DNG] Packaging Vdev

[aitor_czr]

On 03/26/2016 02:53 PM, aitor_czr wrote:


On 03/26/2016 02:28 PM, aitor_czr wrote:

Here you are an experimental packaging of VDEV for amd64 and i386:

http://gnuinos.org/unsystemd/

The repository is:

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

You can import the public key doing:

curl http://gnuinos.org/unsystemd/aitor_pk.asc | apt-key add -

Cheers,

   Aitor.


I have to add the vdev word in the description of libudev-compat. It 
doesn't appear filtering with vdev in synaptic.


  Aitor.


If you download vdev-example.deb, all the paths located in 
/usr/etc/vdev/vdevd.conf must be changed from /usr/local to /usr.


I also should add the following line to vdevd in debian/control.

Provides: udev

More suggestions?

Cheers,

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

Re: [DNG] Packaging Vdev

[aitor_czr]

Hi all,

On 03/24/2016 01:00 PM, aitor_czr  wrote:

In a couple of days i will upload a .deb repository for VDEV.

Cheers,

Aitor.


Here you are an experimental packaging of VDEV for amd64 and i386:

http://gnuinos.org/unsystemd/

The repository is:

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

You can import the public key doing:

curl http://gnuinos.org/unsystemd/aitor_pk.asc | apt-key add -

Cheers,

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

Re: [DNG] Packaging Vdev

[aitor_czr]

Hi all,

In a couple of days i will upload a .deb repository for VDEV.

Cheers,

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

Re: [DNG] Packaging Vdev - compilation errors and patch (Solved)

[aitor_czr]

Hi Didier and Shraptor,

On 03/22/16 23:44, Didier Kryn  wrote:

  I have exactly the same message as you. I bet #include 
is a C++ feature since the file is part of the system include files for
C++. In C one would rather #include  I didn't try to replace
iostream with iostream.h though; may it's just a typo, because this file
is part of the system files for C.

  Didier


I tried again cloning vdev from github, and building in two different 
scenarios:


* Case 1: fskit installed from gitlab. In this case i get the same 
issue: i.e.  isn't found.


* Case 2: fskit installed from github. Vdevfs builds succesfully.

So, the origin of the issue was in the version of fskit.

Cheers,

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[aitor_czr]

On 03/22/2016 07:06 PM, aitor_czr wrote:

Solved doing:

CC:=g++

in the Makefile.


I wanted to say in the buildconf.mk.

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[aitor_czr]

On 03/22/2016 11:44 PM, shraptor  wrote:

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

did

make
make install


on all three consequtively


All built without errors for me and that includes vdevfs



Thanks, i will try tomorrow :)

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[shraptor]

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

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


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

With


gcc --version

gcc (GCC) 5.2.0
...

and then

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

I get



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


with no errors when issuing make -C vdevd

and then tried

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

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

Where did you put your patches?



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


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


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

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

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

  Aitor.
Solved doing:

CC:=g++

in the Makefile. Even though i get some errors:

[...]

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



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


did

make
make install


on all three consequtively


All built without errors for me and that includes vdevfs






[...]

Ok, Jude Nelson advised:

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

  Aitor



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

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[Didier Kryn]

Le 22/03/2016 17:01, aitor_czr a écrit :


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

With

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


and then

git clonehttps://github.com/jcnelson/vdev

I get

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


with no errors when issuing make -C vdevd


and then tried

git clonehttps://git.devuan.org/unsystemd/vdev.git

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


Where did you put your patches?




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

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






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



$ make -C fs
make: Entering directory '/home/aitor/-VDEV/vdev/fs'
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/acl.o" -c 
"acl.c"
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/main.o" -c 
"main.c"

In file included from /usr/include/fskit/fskit.h:25:0,
 from fs.h:27,
 from main.h:26,
 from main.c:22:
/usr/include/fskit/common.h:63:20: fatal error: iostream: No such file 
or directory

 #include 
^
compilation terminated.


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


  Aitor.


I have exactly the same message as you. I bet #include  
is a C++ feature since the file is part of the system include files for 
C++. In C one would rather #include  I didn't try to replace 
iostream with iostream.h though; may it's just a typo, because this file 
is part of the system files for C.


Didier

Didier

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[Didier Kryn]

Le 22/03/2016 15:41, shraptor a écrit :

Where did you put your patches?





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


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

main repo??


I just attached the patches to my previous mail. I compile on 
Debian Wheezy. Maybe
the definitions of minor and major have been moved to another file with 
newer versions of gcc.


Didier

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[aitor_czr]

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


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

With

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


and then

git clonehttps://github.com/jcnelson/vdev

I get

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


with no errors when issuing make -C vdevd


and then tried

git clonehttps://git.devuan.org/unsystemd/vdev.git

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


Where did you put your patches?




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

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






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



$ make -C fs
make: Entering directory '/home/aitor/-VDEV/vdev/fs'
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/acl.o" -c 
"acl.c"
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/main.o" -c 
"main.c"

In file included from /usr/include/fskit/fskit.h:25:0,
 from fs.h:27,
 from main.h:26,
 from main.c:22:
/usr/include/fskit/common.h:63:20: fatal error: iostream: No such file 
or directory

 #include 
^
compilation terminated.


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


  Aitor.


Solved doing:

CC:=g++

in the Makefile. Even though i get some errors:


[...]

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


[...]

Ok, Jude Nelson advised:

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


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

Re: [DNG] Packaging Vdev - compilation errors and patch

[aitor_czr]

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

With

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


and then

git clonehttps://github.com/jcnelson/vdev

I get

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


with no errors when issuing make -C vdevd


and then tried

git clonehttps://git.devuan.org/unsystemd/vdev.git

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


Where did you put your patches?




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

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






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



$ make -C fs
make: Entering directory '/home/aitor/-VDEV/vdev/fs'
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/acl.o" -c "acl.c"
cc -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all 
-pthread -Wno-unused-variable -Wno-unused-but-set-variable -I. 
-I/home/aitor/vdev -I/home/aitor/vdev/build/include -D_THREAD_SAFE 
-D__STDC_FORMAT_MACROS -D_VDEV_OS_LINUX -D_XOPEN_SOURCE=700 
-D_FILE_OFFSET_BITS=64 -o "/home/aitor/vdev/build/usr/sbin/main.o" -c 
"main.c"

In file included from /usr/include/fskit/fskit.h:25:0,
 from fs.h:27,
 from main.h:26,
 from main.c:22:
/usr/include/fskit/common.h:63:20: fatal error: iostream: No such file 
or directory

 #include 
^
compilation terminated.


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


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

Re: [DNG] Packaging Vdev - compilation errors and patch

[shraptor]

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

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

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

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

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


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

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

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



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


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



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

issues on github for those.


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

compile it.



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


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


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

Here is the compilation error:


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

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



With

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


and then

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

I get

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


with no errors when issuing make -C vdevd


and then tried

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

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



Where did you put your patches?





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


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

main repo??





Didier

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

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[aitor_czr]

Hi Didier,

On 03/22/2016 12:06 PM, Didier Kryn  wrote:

kryn@apcnb98:~/Applications/vdev-plus/vdev$ gcc --version
gcc (Debian 4.6.3-14) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
kryn@apcnb98:~/Applications/vdev-plus/vdev$ make -C vdevd
[...]
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In function
`vdev_device_request_to_env':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:257: undefined
reference to `major'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:268: undefined
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In function
`vdev_device_add':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined
reference to `major'
... same for several functions.

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

  Didier


Did you install fskit and pstat? They are required by fs.

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

Re: [DNG] Packaging Vdev - compilation errors and patch

[Didier Kryn]

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

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

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

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


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

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

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



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


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



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

issues on github for those.


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



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


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


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


Here is the compilation error:


kryn@apcnb98:~/Applications/vdev-plus/vdev$ gcc --version
gcc (Debian 4.6.3-14) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
kryn@apcnb98:~/Applications/vdev-plus/vdev$ make -C vdevd
[...]
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In function 
`vdev_device_request_to_env':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:257: undefined 
reference to `major'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:268: undefined 
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/build/sbin/device.o: In function 
`vdev_device_add':
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined 
reference to `minor'
/home/kryn/Applications/vdev-plus/vdev/vdevd/device.c:863: undefined 
reference to `major'

... same for several functions.

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


Didier
diff -rupN vdev/vdevd/device.h vdev-patched/vdevd/device.h
--- vdev/vdevd/device.h	2016-02-14 18:37:43.812467331 +0100
+++ vdev-patched/vdevd/device.h	2016-02-14 18:13:23.561888936 +0100
@@ -22,6 +22,7 @@
 #ifndef _VDEV_DEVICE_H_
 #define _VDEV_DEVICE_H_
 
+#include 
 #include "libvdev/util.h"
 #include "libvdev/param.h"
 #include "workqueue.h"
@@ -110,4 +111,4 @@ int vdev_device_remove( struct vdev_devi
 
 C_LINKAGE_END
 
-#endif
\ No newline at end of file
+#endif
diff -rupN vdev/buildconf.mk vdev-patched/buildconf.mk
--- vdev/buildconf.mk	2016-02-14 18:37:43.756466570 +0100
+++ vdev-patched/buildconf.mk	2016-02-18 11:14:41.604940408 +0100
@@ -69,7 +69,7 @@ BUILD_HWDB_DIRS := $(BUILD_HWDB)
 INSTALL_HWDB := $(DESTDIR)$(LIBDIR)/vdev/hwdb
 
 # compiler
-CFLAGS := -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all -pthread -Wno-unused-variable -Wno-unused-but-set-variable
+override CFLAGS += -Wall -std=c99 -g -fPIC -fstack-protector -fstack-protector-all -pthread -Wno-unused-variable -Wno-unused-but-set-variable
 LDFLAGS:=
 INC  := -I. -I$(ROOT_DIR) -I$(BUILD_INCLUDEDIR)
 DEFS := -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -D_VDEV_OS_$(OS) -D_XOPEN_SOURCE=700
Binary files vdev/.git/index and vdev-patched/.git/index differ
diff -rupN vdev/vdevd/helpers/LINUX/Makefile vdev-patched/vdevd/helpers/LINUX/Makefile
--- vdev/vdevd/helpers/LINUX/Makefile	2015-06-02 21:19:21.631510039 +0200
+++ vdev-patched/vdevd/helpers/LINUX/Makefile	2015-06-02 21:14:52.0 +0200
@@ -15,7 +15,7 @@ all: $(HELPERS_BUILD)
 
 $(BUILD_VDEVD_HELPERS)/%: $(BUILD_VDEVD_HELPERS)/%.o $(BUILD_VDEVD_HELPERS)/common.o
 	@mkdir -p $(shell dirname "$@")
-	$(CC) -o $@ $< $(BUILD_VDEVD_HELPERS)/common.o $(LIBINC) $(LIB)
+	$(CC) -o $@ $< $(BUILD_VDEVD_HELPERS)/common.o $(LIBINC) $(LIB) $(LDFLAGS)
 
 $(BUILD_VDEVD_HELPERS)/%.o: %.c
 	@mkdir -p $(shell dirname "$@")
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[shraptor]

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

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

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


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

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

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



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


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



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

issues on github for those.


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



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


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

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










 Didier


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

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

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

Re: [DNG] Packaging Vdev

[shraptor]

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

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


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

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

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



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


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



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

issues on github for those.


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



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






 Didier


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

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

Re: [DNG] Packaging Vdev

[Didier Kryn]

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


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



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


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




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

issues on github for those.


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


 Didier


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

Re: [DNG] Packaging Vdev

[shraptor]

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

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

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

details that at least I had previously missed.

Thank you for this vital update Didier;-)


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


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



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

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

issues on github for those.





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

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

BTW, any news from Jude?

Didier

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

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

Re: [DNG] Packaging Vdev

[Didier Kryn]

Le 20/03/2016 15:45, Didier Kryn a écrit :

Brief inventory of the files installed on my test bench:
/sbin/vdevd
/lib/vdev: 11 executable binaries and 27 scripts
/lib/vdev/hwdb: one script and a squashfs filesystem (maybe left over 
from building)

/lib/vdev/hwdb/input: 14 text files
/etc/vdev/ifnames.conf
/etc/vdev/vdevd.conf
/etc/acls: 3 files
/etc/actions: 76 text files


Errata on the two last lines. Read

/etc/vdev/acls: 3 text files
/etc/vdev/actions: 76 text files

Didier

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

Re: [DNG] Packaging Vdev

[Didier Kryn]

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

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

Thank you for this vital update Didier;-)


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

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


Brief inventory of the files installed on my test bench:
/sbin/vdevd
/lib/vdev: 11 executable binaries and 27 scripts
/lib/vdev/hwdb: one script and a squashfs filesystem (maybe left over 
from building)

/lib/vdev/hwdb/input: 14 text files
/etc/vdev/ifnames.conf
/etc/vdev/vdevd.conf
/etc/acls: 3 files
/etc/actions: 76 text files

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


BTW, any news from Jude?

Didier

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

Re: [DNG] Packaging Vdev

[Rainer Weikusat]

Hendrik Boom  writes:
> On Sat, Mar 19, 2016 at 07:24:48PM +, Stephanie Daugherty wrote:
>> I would argue vdev belongs in  / rather than /usr because it is likely to
>> be necessary to mount filesystems and such.
>> 
>> The split is somewhat arbitrary these days but historically things needed
>> during the boot process and to repair the system have gone in / while less
>> essential bits have gone into /usr
>> 
>> People do still partition that way sometimes so it's a good idea not to
>> break the system for them :)
>
> My server has been running that way for years, with /usr containing 
> only things not needed during boot. 
>
> Isn't requiring /usr to hae been mounted for booting a systemd-ism?

"Sort of". The justification for the original "Separate /usr is broken"
text was that udev hardcodes /usr-paths, in particular, for its rules
directory.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[aitor_czr]

On 03/20/2016 09:08 AM, Hendrik Boom  wrote:

Still, I'm eagerly awaiting the package, essential or not.

-- hendrik


Hey, be patient !!

Depending of the crazy clock of my Toshiba, they can be available in 2025 :)

Cheers,

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

Re: [DNG] Packaging Vdev

[aitor_czr]

Hi again,

On 03/20/2016 09:08 AM, Didier Kryn  wrote:

Le 19/03/2016 22:00, Daniel Reurich a écrit :

>
>On 20 March 2016 9:07:48 AM NZDT, Didier Kryn  wrote:

>>Le 19/03/2016 21:01, Daniel Reurich a écrit :

>>>On 20/03/16 08:56, Didier Kryn wrote:

>Le 19/03/2016 19:05, aitor_czr a écrit :

>>>Hi all,
>>>
>>>By default, PSTAT (a dependency of VDEV) is installed in

>>"/usr/local",

>>>just as VDEV.
>>>
>>>As Daniel Raurich explained in another thread:
>>>
>>>[...] the "/usr/local" directory is for non-packaged local stuff

>>[...]

>>>So, should i change this configuration for those packages, or

>>should i

>>>skip debhelper's "dh_usrlocal" script adding:
>>>
>>>binary:
>>>  dh binary --before dh_usrlocal
>>>  dh binary --after dh_usrlocal
>>>
>>>to debian/rules?
>>>
>>>Thanks in advance,
>>>
>>> Aitor.
>>>
>>>

>  Jude organized the package like this for people to test it on
>running systems without interfering with the existing hotplugger.

>>Vdev

>would create device files and other descriptive files under
>/usr/local/dev. But, of course it was not meant to remain like this

>>if

>Vdev was to be the hotplugger in charge.
>
>  If it's worth, you might leave it like this until you can get

>>it to

>work and then switch to a normal file hierarchy when ready.
>

>>>I strongly disagree.  If it's to be packaged, it should be packaged
>>>properly in keeping with Debian policies (which Devuan has adopted)

>>with

>>>regards to FHS and location of parts.
>>>
>>>Vdev being an essential system tool should be in the root hierarchy.

>>  I fully agree with you; therefore I don't understand in what you
>>disagree:-)
>>

>You were just suggesting that it would be ok to "leave it like this until you 
can get
>it to work and then switch to a normal file hierarchy when ready".
>
>I'm just stating that I disagree with your premise that creating a package that breaks 
policy is acceptable "until you can get it to work".
>
>If vdev doesn't work already then it's to early to be packaging it.  However 
indications are that it does work and thus it should be properly packaged.
>
>As for testing it should minimally be able to be used successfully debootstrap 
a new system and also to replace udev on a running system without seriously 
breaking anything.
>
>Once it does that we should put it in experimental for wider testing.
>

  Daniel, my point was just practical, although it's obviously
Aitor's buzyness.

  Jude organized his install process so as to put the files under
/usr/local, so that testers could easily test it without interferring
with the hotplugger in function. As such, the package does not need to
exclude Udev.  I tested Vdev with the normal file hierarchy, in a tiny
OS Busybox-based, and I didn't read any report of anyone else having
done so.

  Several months ago, when I stopped testing Vdev in this way, it was
working fine. But the latest version isn't working properly and I don't
know the reason. I cannot exclude that the reason is in handling the
file hierarchy. Vdev manages a lot of files, much more than Udev. OTOH I
didn't read any report of a successful test of this latest version under
/usr/local.

  This is why I suggested to go step by step and not build blindly a
final version of the package which would force the removal of Udev and
replace it with something which doesn't work. But,
again, this was just a friendly suggestion to Aitor, who probably
doesn't need it. And this suggestion caused a useless discussion which
is why I regret to have made it.

  Didier


Ok, being my first atempt, i will respect Jude Nelson's original 
location in "/usr/local" and leave this point for later. Debian's policy 
isn't a priority now. This also will make the job easier. So, for the 
time being, i will skip dh_usrlocal with [*]:


binary:
   dh binary --before dh_usrlocal
   dh binary --after dh_usrlocal

After testing the packages, we will take up this discussion again, if it's 
agreeable to you.

Thanks to all of you,

  Aitor.

[*] Rainer Weikusat (Dng Digest, Vol 11, Issue 86)



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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

 - cut for brevity
>>
>> I'm just stating that I disagree with your premise that creating a
>> package that breaks policy is acceptable "until you can get it to work".
>>
>> If vdev doesn't work already then it's to early to be packaging it. 
>> However indications are that it does work and thus it should be
>> properly packaged.
>>
>> As for testing it should minimally be able to be used successfully
>> debootstrap a new system and also to replace udev on a running system
>> without seriously breaking anything.
>>
>> Once it does that we should put it in experimental for wider testing.
>>
> 
> Daniel, my point was just practical, although it's obviously Aitor's
> buzyness.
> 
> Jude organized his install process so as to put the files under
> /usr/local, so that testers could easily test it without interferring
> with the hotplugger in function. As such, the package does not need to
> exclude Udev.  I tested Vdev with the normal file hierarchy, in a tiny
> OS Busybox-based, and I didn't read any report of anyone else having
> done so.

Right... so only you and presumably Jude have done any real testing of this.
> 
> Several months ago, when I stopped testing Vdev in this way, it was
> working fine. But the latest version isn't working properly and I don't
> know the reason. I cannot exclude that the reason is in handling the
> file hierarchy. Vdev manages a lot of files, much more than Udev. OTOH I
> didn't read any report of a successful test of this latest version under
> /usr/local.

Ok.  So obviously this needs fixing first before even consider building
a package.  Any idea what last version actually built correctly and
worked?  That would be a good starting point.
> 
> This is why I suggested to go step by step and not build blindly a
> final version of the package which would force the removal of Udev and
> replace it with something which doesn't work. But,
> again, this was just a friendly suggestion to Aitor, who probably
> doesn't need it. And this suggestion caused a useless discussion which
> is why I regret to have made it.

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

Thank you for this vital update Didier ;-)

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

Re: [DNG] Packaging Vdev

[Didier Kryn]

Le 19/03/2016 22:00, Daniel Reurich a écrit :


On 20 March 2016 9:07:48 AM NZDT, Didier Kryn  wrote:

Le 19/03/2016 21:01, Daniel Reurich a écrit :

On 20/03/16 08:56, Didier Kryn wrote:

Le 19/03/2016 19:05, aitor_czr a écrit :

Hi all,

By default, PSTAT (a dependency of VDEV) is installed in

"/usr/local",

just as VDEV.

As Daniel Raurich explained in another thread:

[...] the "/usr/local" directory is for non-packaged local stuff

[...]

So, should i change this configuration for those packages, or

should i

skip debhelper's "dh_usrlocal" script adding:

binary:
 dh binary --before dh_usrlocal
 dh binary --after dh_usrlocal

to debian/rules?

Thanks in advance,

Aitor.



 Jude organized the package like this for people to test it on
running systems without interfering with the existing hotplugger.

Vdev

would create device files and other descriptive files under
/usr/local/dev. But, of course it was not meant to remain like this

if

Vdev was to be the hotplugger in charge.

 If it's worth, you might leave it like this until you can get

it to

work and then switch to a normal file hierarchy when ready.


I strongly disagree.  If it's to be packaged, it should be packaged
properly in keeping with Debian policies (which Devuan has adopted)

with

regards to FHS and location of parts.

Vdev being an essential system tool should be in the root hierarchy.

 I fully agree with you; therefore I don't understand in what you
disagree :-)


You were just suggesting that it would be ok to "leave it like this until you 
can get
it to work and then switch to a normal file hierarchy when ready".

I'm just stating that I disagree with your premise that creating a package that breaks 
policy is acceptable "until you can get it to work".

If vdev doesn't work already then it's to early to be packaging it.  However 
indications are that it does work and thus it should be properly packaged.

As for testing it should minimally be able to be used successfully debootstrap 
a new system and also to replace udev on a running system without seriously 
breaking anything.

Once it does that we should put it in experimental for wider testing.



Daniel, my point was just practical, although it's obviously 
Aitor's buzyness.


Jude organized his install process so as to put the files under 
/usr/local, so that testers could easily test it without interferring 
with the hotplugger in function. As such, the package does not need to 
exclude Udev.  I tested Vdev with the normal file hierarchy, in a tiny 
OS Busybox-based, and I didn't read any report of anyone else having 
done so.


Several months ago, when I stopped testing Vdev in this way, it was 
working fine. But the latest version isn't working properly and I don't 
know the reason. I cannot exclude that the reason is in handling the 
file hierarchy. Vdev manages a lot of files, much more than Udev. OTOH I 
didn't read any report of a successful test of this latest version under 
/usr/local.


This is why I suggested to go step by step and not build blindly a 
final version of the package which would force the removal of Udev and 
replace it with something which doesn't work. But,
again, this was just a friendly suggestion to Aitor, who probably 
doesn't need it. And this suggestion caused a useless discussion which 
is why I regret to have made it.


Didier

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

Re: [DNG] Packaging Vdev

[Steve Litt]

I agree with Stephanie.

If a person wants to run sans-initramfs, we don't want to make it
harder for him/her.

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz




On Sat, 19 Mar 2016 19:24:48 +
Stephanie Daugherty  wrote:

> I would argue vdev belongs in  / rather than /usr because it is
> likely to be necessary to mount filesystems and such.
> 
> The split is somewhat arbitrary these days but historically things
> needed during the boot process and to repair the system have gone
> in / while less essential bits have gone into /usr
> 
> People do still partition that way sometimes so it's a good idea not
> to break the system for them :)
> 
> On Sat, Mar 19, 2016, 14:14 Rainer Weikusat
>  wrote:
> 
> > aitor_czr  writes:  
> > > By default, PSTAT (a dependency of VDEV) is installed in
> > > "/usr/local", just as VDEV.
> > >
> > > As Daniel Raurich explained in another thread:
> > >
> > > [...] the "/usr/local" directory is for non-packaged local stuff
> > > [...]
> > >
> > > So, should i change this configuration for those packages, or
> > > should i skip debhelper's "dh_usrlocal" script adding:
> > >
> > > binary:
> > > dh binary --before dh_usrlocal
> > > dh binary --after dh_usrlocal
> > >
> > > to debian/rules?  
> >
> > To which degree this actually makes a difference would be a good
> > question but the convention-so-far has been that distribution
> > provided stuff goes into / or /usr and that /usr/local can be used
> > as seen fit by whoever controls/ administrates a particular
> > installation. If the packaged vdev is supposed to become an
> > integral part of the OS/ distribution, it should honour the
> > existing convention unless there's a good reason for not doing this.
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >  

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

Re: [DNG] Packaging Vdev

[Steve Litt]

On Sun, 20 Mar 2016 08:57:20 +1300
Daniel Reurich  wrote:

> On 20/03/16 08:24, Stephanie Daugherty wrote:

> > The split is somewhat arbitrary these days but historically things 
> > needed during the boot process and to repair the system have gone
> > in / while less essential bits have gone into /usr  
> 
> I don't think the split is arbitrary, although some have worked hard
> to break that structure and smear the history and wisdom of that
> design.

And who might those "some" be who worked hard to break that structure?
Have those same people broken anything else, by any chance?

:-)

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Steve Litt]

On Sat, 19 Mar 2016 15:26:49 -0400
Steve Litt  wrote:

> On Sat, 19 Mar 2016 19:05:20 +0100
> aitor_czr  wrote:
> 
> > Hi all,
> > 
> > By default, PSTAT (a dependency of VDEV) is installed in
> > "/usr/local", just as VDEV.
> > 
> > As Daniel Raurich explained in another thread:
> > 
> > [...] the "/usr/local" directory is for non-packaged local stuff
> > [...]
> > 
> > So, should i change this configuration for those packages, or should
> > i skip debhelper's "dh_usrlocal" script adding:
> > 
> > binary:
> >  dh binary --before dh_usrlocal
> >  dh binary --after dh_usrlocal
> > 
> > to debian/rules?
> > 
> > Thanks in advance,
> > 
> > Aitor.  
> 
> This is pure opinion: Get a second opinion:
> 
> My understanding is that /usr/local is the base of the tree used for
> software *not* installed by the distro's package manager. When I
> compile my own dmenu or lyx, it goes under the /usr/local directory,
> with all executables going in /usr/local/bin.
> 
> My understanding is that the distro's package manager never puts
> anything in the /usr/local tree. If the thing is an executable, it
> goes in /usr/bin. Libraries go in /usr/lib. Header files go
> in /usr/include. Fonts and themes and other stuff like that goes
> in /usr/share.
> 
> If /usr/local/VDEV is a directory, I'd imagine you'd farm out its
> files to the directories listed in the preceding paragraph. If VDEV
> is an executable, it would go in /usr/bin, or perhaps /sbin
> or /usr/sbin.
> 
> Like I say, I'm the world's least authoritative person when it comes
> to package managers, but if I've understood what I've heard others,
> the preceding pretty much sums up what to do.

Stephanie later brought up a reason why it should be on /sbin or
something else always on the root partition, so ignore what I said.

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 20 March 2016 9:07:48 AM NZDT, Didier Kryn  wrote:
>Le 19/03/2016 21:01, Daniel Reurich a écrit :
>> On 20/03/16 08:56, Didier Kryn wrote:
>>> >Le 19/03/2016 19:05, aitor_czr a écrit :
 >>Hi all,
 >>
 >>By default, PSTAT (a dependency of VDEV) is installed in
>"/usr/local",
 >>just as VDEV.
 >>
 >>As Daniel Raurich explained in another thread:
 >>
 >>[...] the "/usr/local" directory is for non-packaged local stuff
>[...]
 >>
 >>So, should i change this configuration for those packages, or
>should i
 >>skip debhelper's "dh_usrlocal" script adding:
 >>
 >>binary:
 >> dh binary --before dh_usrlocal
 >> dh binary --after dh_usrlocal
 >>
 >>to debian/rules?
 >>
 >>Thanks in advance,
 >>
 >>Aitor.
 >>
 >>
>>> >
>>> > Jude organized the package like this for people to test it on
>>> >running systems without interfering with the existing hotplugger.
>Vdev
>>> >would create device files and other descriptive files under
>>> >/usr/local/dev. But, of course it was not meant to remain like this
>if
>>> >Vdev was to be the hotplugger in charge.
>>> >
>>> > If it's worth, you might leave it like this until you can get
>it to
>>> >work and then switch to a normal file hierarchy when ready.
>>> >
>> I strongly disagree.  If it's to be packaged, it should be packaged
>> properly in keeping with Debian policies (which Devuan has adopted)
>with
>> regards to FHS and location of parts.
>>
>> Vdev being an essential system tool should be in the root hierarchy.
>
> I fully agree with you; therefore I don't understand in what you 
>disagree :-)
>

You were just suggesting that it would be ok to "leave it like this until you 
can get
it to work and then switch to a normal file hierarchy when ready".

I'm just stating that I disagree with your premise that creating a package that 
breaks policy is acceptable "until you can get it to work".  

If vdev doesn't work already then it's to early to be packaging it.  However 
indications are that it does work and thus it should be properly packaged.

As for testing it should minimally be able to be used successfully debootstrap 
a new system and also to replace udev on a running system without seriously 
breaking anything.  

Once it does that we should put it in experimental for wider testing.

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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Hendrik Boom]

On Sun, Mar 20, 2016 at 09:01:32AM +1300, Daniel Reurich wrote:
> On 20/03/16 08:56, Didier Kryn wrote:
> > 
> > Jude organized the package like this for people to test it on
> > running systems without interfering with the existing hotplugger. Vdev
> > would create device files and other descriptive files under
> > /usr/local/dev. But, of course it was not meant to remain like this if
> > Vdev was to be the hotplugger in charge.
> > 
> > If it's worth, you might leave it like this until you can get it to
> > work and then switch to a normal file hierarchy when ready.
> > 
> I strongly disagree.  If it's to be packaged, it should be packaged
> properly in keeping with Debian policies (which Devuan has adopted) with
> regards to FHS and location of parts.
> 
> Vdev being an essential system tool should be in the root hierarchy.

It isn't an essential system tool until it works.  So if it'sstill 
being tested, it better not be essential. 

Still, I'm eagerly awaiting the package, essential or not.

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

Re: [DNG] Packaging Vdev

[Hendrik Boom]

On Sat, Mar 19, 2016 at 07:24:48PM +, Stephanie Daugherty wrote:
> I would argue vdev belongs in  / rather than /usr because it is likely to
> be necessary to mount filesystems and such.
> 
> The split is somewhat arbitrary these days but historically things needed
> during the boot process and to repair the system have gone in / while less
> essential bits have gone into /usr
> 
> People do still partition that way sometimes so it's a good idea not to
> break the system for them :)

My server has been running that way for years, with /usr containing 
only things not needed during boot. 

Isn't requiring /usr to hae been mounted for booting a systemd-ism?

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

Re: [DNG] Packaging Vdev

[Didier Kryn]

Le 19/03/2016 21:01, Daniel Reurich a écrit :

On 20/03/16 08:56, Didier Kryn wrote:

>Le 19/03/2016 19:05, aitor_czr a écrit :

>>Hi all,
>>
>>By default, PSTAT (a dependency of VDEV) is installed in "/usr/local",
>>just as VDEV.
>>
>>As Daniel Raurich explained in another thread:
>>
>>[...] the "/usr/local" directory is for non-packaged local stuff [...]
>>
>>So, should i change this configuration for those packages, or should i
>>skip debhelper's "dh_usrlocal" script adding:
>>
>>binary:
>> dh binary --before dh_usrlocal
>> dh binary --after dh_usrlocal
>>
>>to debian/rules?
>>
>>Thanks in advance,
>>
>>Aitor.
>>
>>

>
> Jude organized the package like this for people to test it on
>running systems without interfering with the existing hotplugger. Vdev
>would create device files and other descriptive files under
>/usr/local/dev. But, of course it was not meant to remain like this if
>Vdev was to be the hotplugger in charge.
>
> If it's worth, you might leave it like this until you can get it to
>work and then switch to a normal file hierarchy when ready.
>

I strongly disagree.  If it's to be packaged, it should be packaged
properly in keeping with Debian policies (which Devuan has adopted) with
regards to FHS and location of parts.

Vdev being an essential system tool should be in the root hierarchy.


I fully agree with you; therefore I don't understand in what you 
disagree :-)


Didier

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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 20/03/16 08:56, Didier Kryn wrote:
> Le 19/03/2016 19:05, aitor_czr a écrit :
>> Hi all,
>>
>> By default, PSTAT (a dependency of VDEV) is installed in "/usr/local",
>> just as VDEV.
>>
>> As Daniel Raurich explained in another thread:
>>
>> [...] the "/usr/local" directory is for non-packaged local stuff [...]
>>
>> So, should i change this configuration for those packages, or should i
>> skip debhelper's "dh_usrlocal" script adding:
>>
>> binary:
>> dh binary --before dh_usrlocal
>> dh binary --after dh_usrlocal
>>
>> to debian/rules?
>>
>> Thanks in advance,
>>
>>Aitor.
>>
>>
> 
> Jude organized the package like this for people to test it on
> running systems without interfering with the existing hotplugger. Vdev
> would create device files and other descriptive files under
> /usr/local/dev. But, of course it was not meant to remain like this if
> Vdev was to be the hotplugger in charge.
> 
> If it's worth, you might leave it like this until you can get it to
> work and then switch to a normal file hierarchy when ready.
> 
I strongly disagree.  If it's to be packaged, it should be packaged
properly in keeping with Debian policies (which Devuan has adopted) with
regards to FHS and location of parts.

Vdev being an essential system tool should be in the root hierarchy.

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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 20/03/16 08:24, Stephanie Daugherty wrote:
> I would argue vdev belongs in  / rather than /usr because it is 
> likely to be necessary to mount filesystems and such.

I absolutely agree it should go in /
> 
> The split is somewhat arbitrary these days but historically things 
> needed during the boot process and to repair the system have gone in 
> / while less essential bits have gone into /usr

I don't think the split is arbitrary, although some have worked hard to
break that structure and smear the history and wisdom of that design.

> People do still partition that way sometimes so it's a good idea not 
> to break the system for them :)

Indeed.  Thor

> 
> On Sat, Mar 19, 2016, 14:14 Rainer Weikusat 
>  > wrote:
> 
> aitor_czr > 
> writes:
>> By default, PSTAT (a dependency of VDEV) is installed in 
>> "/usr/local", just as VDEV.
>> 
>> As Daniel Raurich explained in another thread:
>> 
>> [...] the "/usr/local" directory is for non-packaged local stuff 
>> [...]
>> 
>> So, should i change this configuration for those packages, or 
>> should i skip debhelper's "dh_usrlocal" script adding:
>> 
>> binary: dh binary --before dh_usrlocal dh binary --after 
>> dh_usrlocal
>> 
>> to debian/rules?
> 
> To which degree this actually makes a difference would be a good 
> question but the convention-so-far has been that distribution 
> provided stuff goes into / or /usr and that /usr/local can be used
> as seen fit by whoever controls/ administrates a particular 
> installation. If the packaged vdev is supposed to become an integral 
> part of the OS/ distribution, it should honour the existing 
> convention unless there's a good reason for not doing this. 
> ___ 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
> 


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

Re: [DNG] Packaging Vdev

[Didier Kryn]

Le 19/03/2016 19:05, aitor_czr a écrit :

Hi all,

By default, PSTAT (a dependency of VDEV) is installed in "/usr/local", 
just as VDEV.


As Daniel Raurich explained in another thread:

[...] the "/usr/local" directory is for non-packaged local stuff [...]

So, should i change this configuration for those packages, or should i 
skip debhelper's "dh_usrlocal" script adding:


binary:
dh binary --before dh_usrlocal
dh binary --after dh_usrlocal

to debian/rules?

Thanks in advance,

   Aitor.




Jude organized the package like this for people to test it on 
running systems without interfering with the existing hotplugger. Vdev 
would create device files and other descriptive files under 
/usr/local/dev. But, of course it was not meant to remain like this if 
Vdev was to be the hotplugger in charge.


If it's worth, you might leave it like this until you can get it to 
work and then switch to a normal file hierarchy when ready.


Didier

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

Re: [DNG] Packaging Vdev

[Stephanie Daugherty]

I would argue vdev belongs in  / rather than /usr because it is likely to
be necessary to mount filesystems and such.

The split is somewhat arbitrary these days but historically things needed
during the boot process and to repair the system have gone in / while less
essential bits have gone into /usr

People do still partition that way sometimes so it's a good idea not to
break the system for them :)

On Sat, Mar 19, 2016, 14:14 Rainer Weikusat 
wrote:

> aitor_czr  writes:
> > By default, PSTAT (a dependency of VDEV) is installed in "/usr/local",
> > just as VDEV.
> >
> > As Daniel Raurich explained in another thread:
> >
> > [...] the "/usr/local" directory is for non-packaged local stuff [...]
> >
> > So, should i change this configuration for those packages, or should i
> > skip debhelper's "dh_usrlocal" script adding:
> >
> > binary:
> > dh binary --before dh_usrlocal
> > dh binary --after dh_usrlocal
> >
> > to debian/rules?
>
> To which degree this actually makes a difference would be a good
> question but the convention-so-far has been that distribution provided
> stuff goes into / or /usr and that /usr/local can be used as seen fit by
> whoever controls/ administrates a particular installation. If the
> packaged vdev is supposed to become an integral part of the OS/
> distribution, it should honour the existing convention unless there's a
> good reason for not doing this.
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Steve Litt]

On Sat, 19 Mar 2016 19:05:20 +0100
aitor_czr  wrote:

> Hi all,
> 
> By default, PSTAT (a dependency of VDEV) is installed in
> "/usr/local", just as VDEV.
> 
> As Daniel Raurich explained in another thread:
> 
> [...] the "/usr/local" directory is for non-packaged local stuff [...]
> 
> So, should i change this configuration for those packages, or should
> i skip debhelper's "dh_usrlocal" script adding:
> 
> binary:
>  dh binary --before dh_usrlocal
>  dh binary --after dh_usrlocal
> 
> to debian/rules?
> 
> Thanks in advance,
> 
> Aitor.

This is pure opinion: Get a second opinion:

My understanding is that /usr/local is the base of the tree used for
software *not* installed by the distro's package manager. When I
compile my own dmenu or lyx, it goes under the /usr/local directory,
with all executables going in /usr/local/bin.

My understanding is that the distro's package manager never puts
anything in the /usr/local tree. If the thing is an executable, it goes
in /usr/bin. Libraries go in /usr/lib. Header files go in /usr/include.
Fonts and themes and other stuff like that goes in /usr/share.

If /usr/local/VDEV is a directory, I'd imagine you'd farm out its files
to the directories listed in the preceding paragraph. If VDEV is an
executable, it would go in /usr/bin, or perhaps /sbin or /usr/sbin.

Like I say, I'm the world's least authoritative person when it comes to
package managers, but if I've understood what I've heard others, the
preceding pretty much sums up what to do.

SteveT

Steve Litt 
March 2016 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[Rainer Weikusat]

aitor_czr  writes:
> By default, PSTAT (a dependency of VDEV) is installed in "/usr/local",
> just as VDEV.
>
> As Daniel Raurich explained in another thread:
>
> [...] the "/usr/local" directory is for non-packaged local stuff [...]
>
> So, should i change this configuration for those packages, or should i
> skip debhelper's "dh_usrlocal" script adding:
>
> binary:
> dh binary --before dh_usrlocal
> dh binary --after dh_usrlocal
>
> to debian/rules?

To which degree this actually makes a difference would be a good
question but the convention-so-far has been that distribution provided
stuff goes into / or /usr and that /usr/local can be used as seen fit by
whoever controls/ administrates a particular installation. If the
packaged vdev is supposed to become an integral part of the OS/
distribution, it should honour the existing convention unless there's a
good reason for not doing this.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[aitor_czr]

Hi all,

By default, PSTAT (a dependency of VDEV) is installed in "/usr/local", 
just as VDEV.


As Daniel Raurich explained in another thread:

[...] the "/usr/local" directory is for non-packaged local stuff [...]

So, should i change this configuration for those packages, or should i 
skip debhelper's "dh_usrlocal" script adding:


binary:
dh binary --before dh_usrlocal
dh binary --after dh_usrlocal

to debian/rules?

Thanks in advance,

   Aitor.


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

Re: [DNG] Packaging Vdev

[hellekin]

On 03/14/2016 08:04 PM, Rainer Weikusat wrote:
>>>
>>> 0.1.20160314+1deb1
>>>
>>> I was purposing something like this:
>>>
>>> 0.1.d5d965-jessie1
>>>
>>> There is not a great difference between both. If you prefer to use
>>> the date instead of the short commit, i will do so.
>>
>> The whole point with version numbers is to be able to compare them to 
>> know which is more up-to-date.  Wouldn't using a hash conflict with 
>> this?
> 

I suggest using version numbers compatible with [SemVer][0].  It doesn't
strike me as incompatible with Debian versioning and brings some
interesting programmatic advantage to manage dependencies upstream.

If upstream is v0.1.0, you could use: 0.1.0-jude[-devuan-version].
`-devuan-version` would be preceded by a hyphen per the Debian
documentation that was provided in this thread.

The package then would show, e.g., 0.1.0-jude-jessie1.

==
hk

[0]: http://semver.org/ "Semantic Versioning"

-- 
 _ _ We are free to share code and we code to share freedom
(_X_)yne Foundation, Free Culture Foundry * https://www.dyne.org/donate/

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

Re: [DNG] Packaging Vdev

[aitor_czr]

On 03/14/2016 11:55 PM, Daniel Reurich  wrote:

That's only for packages that have been upgraded in the stable release
update.

Actually I'd suggest 0.1.20160314-1 is actually best


Ok, thanks.

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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 15/03/16 11:33, aitor_czr wrote:
> 
> On 03/14/2016 09:04 PM, Daniel Reurich  wrote:
>> On 15/03/16 02:41, aitor_czr wrote:
>>> > 
>>> > On 05/03/16 13:31, aitor_czr wrote:
 >>
 >> Something like this?
 >>
 >> 0.1.20160314+1deb1
>>> > 
>>> > Sorry:
>>> > 
>>> > 0.1.jude20160314+1deb1
>> 0.1.jude20160314-1 is the correct way (according to debian policy).
> 
> I wanted to say +deb1uX
> 
> Currently, debian stable is using +deb8uX
> 
> Isn't it?

That's only for packages that have been upgraded in the stable release
update.

Actually I'd suggest 0.1.20160314-1 is actually best




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

Re: [DNG] Packaging Vdev

[aitor_czr]

On 03/14/2016 09:04 PM, Daniel Reurich  wrote:

On 15/03/16 02:41, aitor_czr wrote:

>
>On 05/03/16 13:31, aitor_czr wrote:

>>
>>Something like this?
>>
>>0.1.20160314+1deb1

>
>Sorry:
>
>0.1.jude20160314+1deb1

0.1.jude20160314-1 is the correct way (according to debian policy).


I wanted to say +deb1uX

Currently, debian stable is using +deb8uX

Isn't it?

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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 15/03/16 01:51, Mat wrote:
> On 05/03/16 14:31, aitor_czr wrote:
>> Hi Daniel, Didier
>>
>>> Le 14/03/2016 00:07, Daniel Reurich a écrit :
> I'd suggest using a version like:
> 0.1.jude+
> That way when Jude does switch to versioned releases we can assume his
> version scheme easily assuming that he starts with > 0.1.
>>
>> Something like this?
>>
>> 0.1.20160314+1deb1
>>
>> I was purposing something like this:
>>
>> 0.1.d5d965-jessie1
>>
> 
> Isn't this one of the typical use-cases of the "epoch" field in debian
> version strings?

Yup, but we can avoid them for this temporary situation until proper
versioning is established.


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

Re: [DNG] Packaging Vdev

[Daniel Reurich]

On 15/03/16 02:41, aitor_czr wrote:
> 
> On 05/03/16 13:31, aitor_czr wrote:
>>
>> Something like this?
>>
>> 0.1.20160314+1deb1
> 
> Sorry:
> 
> 0.1.jude20160314+1deb1

0.1.jude20160314-1 is the correct way (according to debian policy).



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

Re: [DNG] Packaging Vdev

[Mat]

On 05/03/16 14:31, aitor_czr wrote:
> Hi Daniel, Didier
> 
>> Le 14/03/2016 00:07, Daniel Reurich a écrit :
>>> > I'd suggest using a version like:
>>> > 0.1.jude+>> >
>>> > That way when Jude does switch to versioned releases we can assume his
>>> > version scheme easily assuming that he starts with > 0.1.
> 
> Something like this?
> 
> 0.1.20160314+1deb1
> 
> I was purposing something like this:
> 
> 0.1.d5d965-jessie1
> 

Isn't this one of the typical use-cases of the "epoch" field in debian
version strings?

https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

Sorry if I repeat something that has been mentioned already, I didn't
follow the whole thread.

-- 
Mat 



signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging Vdev

[aitor_czr]

On 05/03/16 13:31, aitor_czr wrote:


Something like this?

0.1.20160314+1deb1


Sorry:

0.1.jude20160314+1deb1
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging vdev

[Jude Nelson]

Hi aitor_czr,

On Tue, Nov 10, 2015 at 7:25 AM, aitor_czr  wrote:

> I uploaded fskit to gitlab:
>
> https://git.devuan.org/aitor_czr/fskit/tree/gbp-master
>

That's a very outdated version of fskit.  The latest one (the one
consistent with vdev) is in github:  https://github.com/jcnelson/fskit


>
>
> I didn't see the dpkg template in 'contrib/debian'. That blindness !!
>
> Now, i see some significant differences between this template and mine. In
> my opinion:
>
> 1.- '/usr/lib/libfskit.so' and 'usr/lib/libfskit_fuse.so' dinamical
> libraries must be included in the respective *-dev.install files, instead
> of 'libfskit.install' and 'libfskit-fuse.install'.
>
> 2.- libfskit depends on libfskit-fuse and not the other way around,
> because libfskit-fuse is the backend (I did it so in Netman).
>
> Isn't it?
>

It's the other way around:  libfskit-fuse depends on libfskit.  But unless
you're packaging vdevfs along with vdevd, you don't need libfskit at all :)

HTH,
Jude


>
>
> Aitor.
>
> On 11/08/2015 02:38 PM, shraptor 
>   wrote:
>
> Sorry read a little bit fast there, thought you was building vdev but
> you are working on fskit
>
>
> anyway default is */usr/local/lib/**
> Defaults can be overridden in buildconf.mk
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Packaging vdev

[aitor_czr]

Ok, Jude.

Thanks :)

On 10/11/15 20:43, Jude Nelson wrote:

Hi aitor_czr,

On Tue, Nov 10, 2015 at 7:25 AM, aitor_czr > wrote:


I uploaded fskit to gitlab:

https://git.devuan.org/aitor_czr/fskit/tree/gbp-master


That's a very outdated version of fskit.  The latest one (the one 
consistent with vdev) is in github: https://github.com/jcnelson/fskit




I didn't see the dpkg template in 'contrib/debian'. That blindness !!

Now, i see some significant differences between this template and
mine. In my opinion:

1.- '/usr/lib/libfskit.so' and 'usr/lib/libfskit_fuse.so'
dinamical libraries must be included in the respective
*-dev.install files, instead of 'libfskit.install' and
'libfskit-fuse.install'.

2.- libfskit depends on libfskit-fuse and not the other way
around, because libfskit-fuse is the backend (I did it so in Netman).

Isn't it?


It's the other way around:  libfskit-fuse depends on libfskit.  But 
unless you're packaging vdevfs along with vdevd, you don't need 
libfskit at all :)


HTH,
Jude


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

Re: [DNG] Packaging vdev

[aitor_czr]

Hi Jude,

I just saw the header:

#include 

in "fuse/fskit_fuse.h". So 'libfskit-fuse' depens on 'libfskit'.

Thanks,

 Aitor.

On 10/11/15 20:43, Jude Nelson wrote:

Hi aitor_czr,

On Tue, Nov 10, 2015 at 7:25 AM, aitor_czr > wrote:


I uploaded fskit to gitlab:

https://git.devuan.org/aitor_czr/fskit/tree/gbp-master


That's a very outdated version of fskit.  The latest one (the one 
consistent with vdev) is in github: https://github.com/jcnelson/fskit




I didn't see the dpkg template in 'contrib/debian'. That blindness !!

Now, i see some significant differences between this template and
mine. In my opinion:

1.- '/usr/lib/libfskit.so' and 'usr/lib/libfskit_fuse.so'
dinamical libraries must be included in the respective
*-dev.install files, instead of 'libfskit.install' and
'libfskit-fuse.install'.

2.- libfskit depends on libfskit-fuse and not the other way
around, because libfskit-fuse is the backend (I did it so in Netman).

Isn't it?


It's the other way around:  libfskit-fuse depends on libfskit.  But 
unless you're packaging vdevfs along with vdevd, you don't need 
libfskit at all :)


HTH,
Jude


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

Re: [DNG] Packaging vdev

[aitor_czr]

I uploaded fskit to gitlab:

https://git.devuan.org/aitor_czr/fskit/tree/gbp-master

I didn't see the dpkg template in 'contrib/debian'. That blindness !!

Now, i see some significant differences between this template and mine. 
In my opinion:


1.- '/usr/lib/libfskit.so' and 'usr/lib/libfskit_fuse.so' dinamical 
libraries must be included in the respective *-dev.install files, 
instead of 'libfskit.install' and 'libfskit-fuse.install'.


2.- libfskit depends on libfskit-fuse and not the other way around, 
because libfskit-fuse is the backend (I did it so in Netman).


Isn't it?

Aitor.

On 11/08/2015 02:38 PM, shraptor  wrote:

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


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


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

Re: [DNG] Packaging vdev

[shraptor]

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

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

Hi all,

I just started with fskip:

http://gnuinos.org/vdev/

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


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

i.e

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

??


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


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










Cheers,

   Aitor.

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

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

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

Re: [DNG] Packaging vdev

[aitor_czr]

Hi Shraptor,

Yes, i had a look at buildconf.mk...

Anyway, building sources the DESTDIR is /usr/local, but not packaging...

I will try using CMake.

Thanks,

  Aitor.

On 11/08/2015 02:31 PM, shraptor wrote:

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


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


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

Re: [DNG] Packaging vdev

[Jack L. Frost]

On Sat, Nov 07, 2015 at 10:09:19PM +0100, aitor_czr wrote:
> Hi all,
> 
> I just started with fskip:
> 
> http://gnuinos.org/vdev/
> 
> It builds successfully, but after a installation i saw the following issue:
> all the /usr/lib/*.o files are missing !!
> 
> Cheers,
> 
>Aitor.

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

You might want to look at my Arch vdev and vdev-related packages:

https://pkg.fleshless.org/vdev-git/tree/PKGBUILD
https://pkg.fleshless.org/libpstat-git/tree/PKGBUILD
https://pkg.fleshless.org/fskit-git/tree/PKGBUILD

They are bash scripts, so you should have no trouble understanding them.
It might save you from figuring everything out on your own.


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

Re: [DNG] Packaging vdev

[aitor_czr]

Thanks, Jack, i will have a look at your work.

Have a nice day,

Aitor.

On 11/08/2015 11:57 PM, Jack L. Frost wrote:

You might want to look at my Arch vdev and vdev-related packages:

https://pkg.fleshless.org/vdev-git/tree/PKGBUILD
https://pkg.fleshless.org/libpstat-git/tree/PKGBUILD
https://pkg.fleshless.org/fskit-git/tree/PKGBUILD

They are bash scripts, so you should have no trouble understanding them.
It might save you from figuring everything out on your own.


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