Re: [DNG] Popularity-contest for Devuan

[Daniel Reurich]

>>
> Don't know if this is related to the repo issues or something wrong this
> end but I get the following from Cron Daemon
> 
> Subject: Crontest -x /etc/cron.daily/popularity-contest
>  &&
> /etc/cron.daily/popularity-contest
>  --crond
> 
> gpg: 4383FF7B81EEE66F: skipped: public key not found
> gpg: /var/log/popularity-contest.new: encryption failed: public key not
> found.
> 
> thanks
> 
> Rob
> 

what version of popularity-contest do you have installed?


-- 
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] files.devuan.org not working

[Linux O'Beardly]

Do we know when this will be fixed? It's really hard to spread the gospel
of Devuan if my disciples can't get to the source of enlightenment.

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com

On Thu, Mar 24, 2016 at 4:13 PM, Jaromil  wrote:

>
>
> ok I understand now the problem is limited to https
>
> the old yearly certs have expired,
> meanwhile hellekin is working on a new setup
> which is based on let's encrypt
>
> so please be patient :^)
> this is one of the reasons why we don't call it beta yet
>
> 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] Making sense of C pointer syntax.

[Rainer Weikusat]

Hendrik Boom  writes:
> On Tue, Mar 29, 2016 at 02:46:50PM +0100, Rainer Weikusat wrote:
>> This is a wrong assumption and it relies on behaviour the C standard
>> doesn't guarantee. Any pointer may be converted (it's even converted
>> automatically as required) to a void * and back and
>> 
>> "the result shall compare equal to the original pointer"
>> 
>> But a pointer to a void * is an entirely different animal and no such
>> guarantees are made for that. This will work in practice if there's only
>> one 'machine pointer type' anyway, though. But using it is not necessary
>> as void * is sufficient.
>
> Last time I looked at the C standard (which was a while ago, things may
> have changed) function pointers were not guaranteed to be 
> interconvertable with data pointers.

Indeed. I didn't remember this while writing the text.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Hendrik Boom]

On Tue, Mar 29, 2016 at 02:46:50PM +0100, Rainer Weikusat wrote:

> This is a wrong assumption and it relies on behaviour the C standard
> doesn't guarantee. Any pointer may be converted (it's even converted
> automatically as required) to a void * and back and
> 
> "the result shall compare equal to the original pointer"
> 
> But a pointer to a void * is an entirely different animal and no such
> guarantees are made for that. This will work in practice if there's only
> one 'machine pointer type' anyway, though. But using it is not necessary
> as void * is sufficient.

Last time I looked at the C standard (which was a while ago, things may
have changed) function pointers were not guaranteed to be 
interconvertable with data pointers.  You could cast them back and 
forth, but there was no guarantee they would survive the round trip.

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

[DNG] Networking, dependencies, restarting

[Steve Litt]

Hi all,

Right now, on the debian-user mailing list, they're wringing their
hands about restarting the network and how Debian apparently gets it
wrong, I guess because of stuff like you need a link before assigning
an IP, you need an IP before doing DNS, you need DNS before NFS,
Samba, Apache and who knows what else. And I think they're also having
problems with recognizing the right network device names, which of
course was solved on this mailing list a couple months ago.

LOL.

First of all, it's ironic that if I had credible information on startup
ordering, and if I used systemd, I could *easily* get all this to
happen. Systemd's Unit files with targets and the like are straight up
built for this exact multiple ordering thing.

Similarly, I could get this to happen on Runit or S6, with generic
dependencies. It appears that the Debian Devs are doing their systemd
with a sysvinit accent. Worst of both worlds.

OK, I'll stop with my gleeful "I told you so" taunt, and get to my
real message...

In my personal opinion, you can't make a distro for every use case, for
ever event. And the more you try to get those last couple percent to
work, the bigger and messier the system becomes.

I think the best way to get that last couple percent is with
documentation and shellscripts. This works because generally speaking,
the people with use cases that break the normal distro methods are
informed enough to read docs and modify shellscripts. So for instance,
on a machine that just assigns a static IP address and gateway, you
might use a shellscript something like this:

===
#!/bin/sh
hostname -F /etc/hostname
ip link set dev lo up
ip link set dev $eth down
ip addr add 192.168.100.88/24 dev $eth
ip link set dev $eth up
ip route add default via 192.168.100.96

if ping -c1 192.168.100.96; then
   start_nfs.sh
   start_samba.sh
   start_apache.sh
   start_smtp_server.sh
fi
===

In the preceding, the value of $eth would have already been determined
by the device name finding shellscript described a few months ago on
this mailing list. The ping -c1 192.168.100.96 is how you prove you
have network connectivity. In reality, that and all the start_*.sh
scripts would have probably been scripts that left evidence of their
starting or failure somewhere.

A slightly more sophisticated version of the preceding script would
probably start up the network and everything needing it. And when it
comes time to stop the network, it could be something like this:

==
stop_smtp_server.sh
stop_apache.sh
stop_samba.sh
stop_nfs.sh
if dependent_services_really_stopped.sh; then
ip link set dev $eth down
==

A restart is just a stop and subsequent start.

Here's my point: For 98% of all users, starting and stopping via
sysvinit, you know, what we and Debian have right now, works just fine.
But for those edge cases, rather than building ever more IF statements
into ever huger init scripts, why not document a few skeleton
shellscripts that can be custom modified to do *exactly* what's needed
in the (presumably sophisticated) user's case?

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] devuan installer main menu access

[Rainer Weikusat]

Boruch Baum  writes:

[...]

> 4] The third set of downloads, for the additional system components,
> should have been the easy lift. What I did was deselect the options for
> a desktop and for a print server, expecting the system to want to
> download ~273 files, as it did on prior tests. At that point, I tried
> doing what I had no problem doing for the prior two stages - return to
> the main install menu, and open up a shell. I tabbed to 'go back',
> pressed 'enter', but the installer began downloading packages instead of
> presenting the main menu, and indicated that it would download 1173
> packages instead of 273.

It's been a long time since I used that but you should have a shell
available on the 2nd VT.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Rainer Weikusat]

Steve Litt  writes:
> On Mon, 28 Mar 2016 13:57:08 -0300
> Emiliano Marini  wrote:
>
>> char *p;
>> p="01234";  /* skeezy, but makes the point */
>> 
>> Warning! Here "p" is pointing to nowhere, you don't know which memory
>> locations are writing to.
>
> Yeah, that's why I said "skeezy". But on some of compilers, you can
> actually strcpy(p, "43210") and you will neither get a compile time
> error nor a runtime one, because when p is in scope, it points to 6
> bytes *somewhere*, even if on the stack.

That's not necessarily true. Eg, on a 64-bit Intel machine using gcc
4.7.2, this program


static long long *llp(void)
{
long long x;

x = -2;
return 
}

static void *ouch(void)
{
char *p;

*p = 3;
return 
}

int main(void)
{
llp();
ouch();

return 0;
}


will segfault because the pointer gets the value assigned to the long
long used earlier.


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

Re: [DNG] Making sense of C pointer syntax.

[Rainer Weikusat]

Edward Bartolo  writes:
> Hi,
>
> Thanks for dedicating some of your time to answer me. I used:
>
> void change_value(void** ptr)
>
> Because I wanted to enable myself to allocate memory for the pointer
> inside the function, therefore I needed a pointer to a pointer of type
> void.

This is a wrong assumption and it relies on behaviour the C standard
doesn't guarantee. Any pointer may be converted (it's even converted
automatically as required) to a void * and back and

"the result shall compare equal to the original pointer"

But a pointer to a void * is an entirely different animal and no such
guarantees are made for that. This will work in practice if there's only
one 'machine pointer type' anyway, though. But using it is not necessary
as void * is sufficient.


#include 
#include 

enum {
CHAR =  1,
SHORT = sizeof(short),
INT =   sizeof(int),
LLONG = sizeof(long long)
};

static void alloc_int(void *p, int which)
{
void *area;

area = malloc(which);
switch (which) {
case CHAR:
*(char **)p = area;
break;

case SHORT:
*(short **)p = area;
break;

case INT:
*(int **)p = area;
break;

case LLONG:
*(long long **)p = area;
}
}

int main(void)
{
unsigned long long *pll;

alloc_int(, LLONG);
*pll = -1;
printf("%llx\n", *pll);

return 0;
}


NB: That's seriously bizarre code.

[...]

> This is a program employing the use of a pointer to change the value
> of a parameter inside a function.
>
> #include 
> #include 
>
> int afunc(double* dd) {
>   *dd *= 2;
> }

There's a return statement missing here or the declared return value is
wrong. It's a good idea to enable compiler warnings when compiling as
this means the compiler will - well - warn about such issues:

[rw@doppelsaurus]/tmp#gcc -W -Wall b.c
b.c: In function 'afunc':
b.c:6:1: warning: control reaches end of non-void function [-Wreturn-type]

Also, to state this again: C is not Pascal and doesn't distinguish
between 'subprograms which may return values and should/ must not have
side effects' (function) and 'subprograms which are executed for the
side effects but cannot return values except by using output
parameters'. When you're writing C, use the return value to return
values, eg

double afunc(double in)
{
return in * 2;
}

[...]

> The reason for this is the fact that a pointer is a number.

A machine address may be a number but a pointer isn't. That's something
abstract defined by C as having certain properties. Among these are that
pointers may be converted to integers and vice versa but the effect is
implementation dependent and the behaviour may be undefined. Again,
provided the integer has a sufficient size, this will usually
work. There are also optional types intptr_t and uintptr_t guaranteed to
be capable of storing the value of a void *.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Making sense of C pointer syntax.

[Emiliano Marini]

This is correct:

int **L ===> Address1(preallocated) -> Address2(not allocated) ->
> int (not allocated)
>

When you declare a variable, the compiler will reserve memory space to
store it.

No matter how may asterisks a variable has, from the compiler's view it's
only a memory address. So it will reserve space to store an address:

int *x;

x will store a memory address, so the compiler has to reserve 8 bytes
(amd64) for it.

Conclusion: the size of a pointer will be always the same, no matter what
is pointing to (an integer, a char, an address...)


On Tue, Mar 29, 2016 at 9:00 AM, Edward Bartolo  wrote:

> Hi,
>
> As far as I know, the compiler automatically allocates memory for the
> address where a pointer is saved. The unallocated part is the data
> attached to a pointer. What happens with a pointer to a pointer like
> void**? Does the compiler allocate memory for two addresses with the
> first one in the chain pointing to the second one? Does it allocate
> memory only for the first address?
>
> What I can say about pointers:
>
> a) int * K ===>Address(preallocated) ---> integer
> [ not preallocated ]
>
> b) void** V ===> Address1 (preallocated) --> Address2(preallocated)
>
> OR:
>
> void** V ===> Address1 (preallocated) -> Address2(not preallocated)
>
> ?
>
> c) int **L ===> Address1 (preallocated) -> Address2(allocated)
> -> int (not allocated)
>
> OR
>
> int **L ===> Address1(preallocated) -> Address2(not allocated)
> -> int (not allocated)
>
> By 'preallocated' I mean the compiler will automatically generate code
> to allocate memory for the actual pointer not the data.
>
> d) Is this allowed: void***, int***, double***, etc?
> ___
> 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] Making sense of C pointer syntax.

[Edward Bartolo]

Hi,

As far as I know, the compiler automatically allocates memory for the
address where a pointer is saved. The unallocated part is the data
attached to a pointer. What happens with a pointer to a pointer like
void**? Does the compiler allocate memory for two addresses with the
first one in the chain pointing to the second one? Does it allocate
memory only for the first address?

What I can say about pointers:

a) int * K ===>Address(preallocated) ---> integer
[ not preallocated ]

b) void** V ===> Address1 (preallocated) --> Address2(preallocated)

OR:

void** V ===> Address1 (preallocated) -> Address2(not preallocated)

?

c) int **L ===> Address1 (preallocated) -> Address2(allocated)
-> int (not allocated)

OR

int **L ===> Address1(preallocated) -> Address2(not allocated)
-> int (not allocated)

By 'preallocated' I mean the compiler will automatically generate code
to allocate memory for the actual pointer not the data.

d) Is this allowed: void***, int***, double***, etc?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] devuan installer main menu access

[Boruch Baum]

On 03/29/2016 12:33 AM, Gregory Nowak wrote:
> On Mon, Mar 28, 2016 at 06:30:42PM -0400, Boruch Baum wrote:
>> 4.1] Was it a case of 'fat-fingerng'? I don't think so, but it's
>> asking a lot to attempt to re-create this because with slow
>> bandwidth, each install attempt takes a long time to get to this
>> stage. Today's connection was especially slow. This has been the
>> only time and point in the install process that I've had a problem
>> returning to the main menu, so it might have been an errant
>> keystroke, but I think I was being careful.
> 
> You had previously indicated you have other debian/devuan boxes on
> your network.
Did not. Don't.

> Is there any reason why you can't install apt-cacher-ng on one of
> them?
See above.

> You could then experiment with as many install attempts as you
> want without having to download the same packages all over again.
What I did write in the past, in response to Adam Borowski's identical
suggestion, was that its asking a lot of a potential contributor to
require multiple machines, a network, and the additional software, for
something that could easily have been solved by either: 1] not being
stingy on the initial download, ie. offering a full iso instead of a
netboot, or 2] having the netboot installer also refer to a local cache.
Also, how many other linux distributions make that kind of request?

I'll mention one solution I didn't offer before because its performance
might not be as fast - use the extra space on the install medium. -IF-
the install medium is a new-ish USB stick, then it likely has a capacity
of 8/16/32 GB, and if the target is USB3-equipped, then the transfer
speeds should be good. The installer already sets up a small writable
FIRMWARE partition on the install media, so this additional suggestion
would be to not let the rest of the install media go to waste - use it
as a local cache.

-- 
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

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

Re: [DNG] Making sense of C pointer syntax.

[Edward Bartolo]

Hi,

Sometimes, a generic pointer is very useful. For instance, the Windows
API documents functions that have untyped pointers. These allow great
flexibility and behave like the variant type in other languages but
with efficient memory consumption. Delphi Pascal has both the variant
and untyped pointer types. This clearly shows there are advantages to
having the possibility of using untyped pointers. The Windows API
CreateProcess function is such an example.

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

Re: [DNG] Making sense of C pointer syntax.

[KatolaZ]

On Mon, Mar 28, 2016 at 09:55:08PM +0200, Edward Bartolo wrote:
> Hi,
> 
> Thanks for dedicating some of your time to answer me. I used:
> 
> void change_value(void** ptr)
> 
> Because I wanted to enable myself to allocate memory for the pointer
> inside the function, therefore I needed a pointer to a pointer of type
> void. Void allows such a function to handle different data types in
> which case an ordinal typed parameter may be used to allow a switch
> statement within the function to handle the different data types. I
> used such a construct in Delphi Pascal in the past, and consider it a
> powerful feature that can have its uses. This is why I am anxious to
> comprehend the why behind pointer to pointer use.
> 

Allocating memory for a generic variable into a function is seldom of
any use, since you need to specify how much memory (number of bytes)
your function should allocate anyway. Although it is still possible to
code such a function, I think it is in general a bad idea. Why don't
you use malloc directly for this purpose? 

Producing good-quality and maintanable software is also about
providing clean interfaces to the user, and by "interface" I mean
function signatures, which should be self-explanatory and clear. If I
can get almost anything as a result value of a function call, then
that function is likely to become a can of worms...

My2Cents

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng