[DNG] Problem with debhelper
Recently i debianized the latest release of bulmages (acounting and invoicing program) in Qt5: http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages And i had the following issue: the resulting packages were all empty! This was due to the fact that the latest release is located in /usr/local, so i had to comment with some lines in the dh_usrlocal script, written in perl by Joey Hess. For example: ## doit(rmdir $tmp/usr/local); Is there any way avoid that? Is this a bug in dh? Thanks in advance. Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Mirroring Devuan
On 20/08/15 04:21, Hendrik Boom wrote: On Wed, Aug 19, 2015 at 10:42:29AM +0200, Jaromil wrote: dear Karl, thanks for your analysis we haven't yet worked on the mirroring mechanism, but we will once done, there will be a script and it will be easy I guess it will be a sort of amprolla satellite process so that the mirror redirection will be handled by nextime's software however it is sort of low priority for now but good to remind nextime about this one soon he'll be having some beach coding time ;-) You mean that when I went through the insttaller step of choosing a devuan mirror, they all pointed to the same place? Yup, but given that httpredir all the debian packages should come from your local debian mirror anyway - and that's still 95% of packages for a standard install. However, we're working on a mechanism to improve the use of local mirrors for where httpredir for debian gets it wrong (like it does for me in NZ). We may also extend this for deb-multimedia to use local mirrors too. Once we've got a beta for devuan out the I'll work with nextime to produce a package for amprolla that makes building private mirrors a walk in the park, and also will make building official CC mirrors easier too. Regards, Daniel. -- Daniel Reurich Centurion Computer Technology (2005) Ltd. 021 797 722 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Problem with debhelper
aitor_czr aitor_...@gnuinos.org writes: Recently i debianized the latest release of bulmages (acounting and invoicing program) in Qt5: http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages And i had the following issue: the resulting packages were all empty! This was due to the fact that the latest release is located in /usr/local, so i had to comment with some lines in the dh_usrlocal script, written in perl by Joey Hess. For example: ## doit(rmdir $tmp/usr/local); Is there any way avoid that? Is this a bug in dh? Use it as intended? In case you want to create a package installing something in /usr/local (eg, because it's a local package not intended for standalone distribution), the dh_usrlocal step can be skipped: binary: dh binary --before dh_usrlocal dh binary --after dh_usrlocal ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] *****SPAM***** Re: C string handling
Spam detection software, running on the system tupac2, has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 22/08/2015 16:40, Rainer Weikusat wrote: [*] In theory. In practice, people working on glibc are mad scientist-style x86 machine code hackers and the actual implementation of something like strcpy might (and likely will) be anything but straight-forward. [...] Content analysis details: (5.3 points, 5.0 required) pts rule name description -- -- 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [82.216.6.62 listed in dnsbl.sorbs.net] 1.7 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: musl-libc.org] 3.6 RCVD_IN_PBLRBL: Received via a relay in Spamhaus PBL [82.216.6.62 listed in zen.spamhaus.org] ---BeginMessage--- On 22/08/2015 16:40, Rainer Weikusat wrote: [*] In theory. In practice, people working on glibc are mad scientist-style x86 machine code hackers and the actual implementation of something like strcpy might (and likely will) be anything but straight-forward. That's the reason why my go-to reference for C library implementation is not the glibc, but musl: http://musl-libc.org/ -- Laurent ---End Message--- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Problem with debhelper
Thaks, i will try it. Aitor. On 22/08/15 16:58, Rainer Weikusat rainerweiku...@virginmedia.com wrote: Use it as intended? In case you want to create a package installing something in /usr/local (eg, because it's a local package not intended for standalone distribution), the dh_usrlocal step can be skipped: binary: dh binary --before dh_usrlocal dh binary --after dh_usrlocal aitor_czraitor_...@gnuinos.org writes: Recently i debianized the latest release of bulmages (acounting and invoicing program) in Qt5: http://gnuinos.org/release16/?dir=devuan/pool/main/b/bulmages And i had the following issue: the resulting packages were all empty! This was due to the fact that the latest release is located in /usr/local, so i had to comment with some lines in the dh_usrlocal script, written in perl by Joey Hess. For example: ## doit(rmdir $tmp/usr/local); Is there any way avoid that? Is this a bug in dh? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] CLI backend: (E)SSID issues
On Sat, 22 Aug 2015 23:57:54 +0200 tilt! t...@linuxfoo.de wrote: Hello, it has come to my attention that an SSID is defined by a (closed) IEEE standard as (I quote inofficial source [1]): [...] 0-32 octets with arbitrary contents. A 0-length SSID indicates the wildcard SSID (in probe request frames for instance) This means that #1 SSIDs can have length zero. #2 SSIDs can contain the zerobyte. In the context of the CLI Back-En's (E)SSID encoder, this has the following consequences: a) I refuse to support case #1. It is a special case that to the extent of my knowledge only has use in special purpose frames exchanged in procedures of broadcasting or ad-hoc networking. If someone shows me otherwise, I will reconsider; it's of course not impossible to support it, just additional effort. b) I am currently unable to support case #2, because the frontend does not pass the information length of the SSID to the backend. Instead it passes ans an entry of argv[] a C-type string which is a sequence of nonzero bytes terminated by a zerobyte. Thus, the backend is not capable of receiveing an SSID completely that contains the zerobyte, and furthermore, the backend had no way of determining the actual length of the SSID in bytes. Ceterum censeo standards should be open. If somebody's silly enough to put nullbytes in their ESSID or have it blank (as opposed to not advertised), then I don't want to use their silly setup. I think it's perfectly fine not to support those two IMHO ridiculous situations. SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On Sat, 22 Aug 2015 21:46:05 +0200 tilt! t...@linuxfoo.de wrote: I agree with Laurent, the RCVD_IN_DYNABLOCK rule weight should be lowered below treshhold, because 1. it's incorrect to mark a mail as spam solely based on this criterion, because a significant portion of internet users are in dynablocks, and not all of them are spammers; 2. the list already has moderation in place for off-list mails, so why be so rigid. 3. Because if we start blowing off people with confirmed records of writing code, such as Laurent has done with s6, then what would distinquish our list from Debian-User? SteveT Steve Litt August 2015 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
My address sometimes gets blocked as coming from a dynamically assigned IP address, even though the IP address is a static address. Okay, that's odd. But what could the ISP do about it? list services that use PBL are not a good idea and serve the interests that are exactly opposite to the Devuan philosophy. It's a trade-off, as usual. I don't know how much actual spam gets filtered out, so I can't tell whether the trade-off is worth it. I'm not letting ISPs take over users' freedom to host their own MTAs, and you should not either. :P My ISP doesn't filter my connection, so they're holding to their end of the deal. Beyond that, there's really nothing they could do about foreign MTAs refusing to accept mail from here. But I still want to run a local MTA, and I do, as my mail headers should confirm. I am just forced to send outgoing mail via a relay (incoming mail is handed to postfix by fetchmail). It is unfortunate, but still the least painful feasible way of doing EMail these days, given the constraints, apart from throwing money at it. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] C string handling
Gentlemen, On 08/22/2015 04:40 PM, Rainer Weikusat wrote: Roger Leigh rle...@codelibre.net writes: On 20/08/2015 11:27, Rainer Weikusat wrote: Roger Leigh rle...@codelibre.net writes: On 19/08/2015 17:39, Rainer Weikusat wrote: [...] p_len = strlen(IFACES_PATH); e_len = strlen(essid); path = alloca(p_len + e_len + 2); strcpy(path, IFACES_PATH); path[p_len] = '/'; strcpy(path + p_len + 1, essid); [...] I am fully aware of the C string problem. The code has other problems, too. Edward is not to blame for this at all, because he is no C programmer. I am using Edward's submission as template for what the back-end must understand as arguments, what commandlines it must execute, what it is supposed to print, how it is supposed to exit etc. (think contract programming). Believe me, I already rewrote specifically this section of the code, so don't bother too much. On a sidenote, I try to get rid of the exec()s and replace them with execl()s. I hope the surrounding PASCAL process thread can handle that in terms of catching the stdout. Kind regards, T. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *****SPAM***** Re: C string handling
On Sat, Aug 22, 2015 at 05:20:15PM +0200, Timo Buhrmester wrote: from my legitimate IP 0.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address [82.216.6.62 listed in dnsbl.sorbs.net] Note the 'dynamic'. I wouldn't quite take this personally, and I doubt anyone on the list is to blame for that, with the possible exception of yourself for not arranging yourself around the fact that these days, MTAs behind dynamic IPs are automatically suspicious. My address sometimes gets blocked as coming from a dynamically assigned IP address, even though the IP address is a static address. My ISP says they're onto it, but from the results they got it seems to me that the Trend antispam organisation isn't interested. -- hendrik Yes, it sucks, I have the same problem, MXs typically don't even accept mail directly from here. No, it doesn't help to whine about it. ___ 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] *****SPAM***** Re: C string handling
On 22/08/2015 16:58, Laurent Bercot wrote: Spam detection software, running on the system tupac2, has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Oh, for fuck's sake. If I can't post legitimate mails to the list from my legitimate IP and link a legitimate site without being barked at by deficient antispam software, I guess it's time for me to leave. -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
