unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* [PATCH] gnu: Add whois.
@ 2016-10-18  8:04 ng0
  2016-10-18  8:04 ` ng0
  2017-01-04 17:41 ` ng0
  0 siblings, 2 replies; 13+ messages in thread
From: ng0 @ 2016-10-18  8:04 UTC (permalink / raw)
  To: guix-devel

For "historic" reasons this also bundles mkpasswd to encrypt passwords.
I don't want to unbundle this right now, this should be a job for upstream.

PPoint is: A whois client for guix. We have no whois right now. Well that is if
you see the very limited one of bind as a client, then we do have one.

whois hackint.eu worked (the bind one just tells you "i don't know .eu what is .eu ..."),
so I assume it is functional.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] gnu: Add whois.
  2016-10-18  8:04 [PATCH] gnu: Add whois ng0
@ 2016-10-18  8:04 ` ng0
  2016-10-18 13:03   ` Marius Bakke
  2016-10-24 16:52   ` Marius Bakke
  2017-01-04 17:41 ` ng0
  1 sibling, 2 replies; 13+ messages in thread
From: ng0 @ 2016-10-18  8:04 UTC (permalink / raw)
  To: guix-devel

* gnu/packages/networking.scm (whois): New variable.
---
 gnu/packages/networking.scm | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/gnu/packages/networking.scm b/gnu/packages/networking.scm
index 4b77aad..eb0f3de 100644
--- a/gnu/packages/networking.scm
+++ b/gnu/packages/networking.scm
@@ -47,6 +47,7 @@
   #:use-module (gnu packages gettext)
   #:use-module (gnu packages gnupg)
   #:use-module (gnu packages gtk)
+  #:use-module (gnu packages libidn)
   #:use-module (gnu packages linux)
   #:use-module (gnu packages lua)
   #:use-module (gnu packages mit-krb5)
@@ -423,6 +424,43 @@ and up to 1 Mbit/s downstream.")
     ;; src/md5.[ch] is released under the zlib license
     (license (list license:isc license:zlib))))
 
+(define-public whois
+  (package
+    (name "whois")
+    (version "5.2.12")
+    (source
+     (origin
+       (method url-fetch)
+       (uri (string-append "mirror://debian/pool/main/w/whois/"
+                           name "_" version ".tar.xz"))
+       (sha256
+        (base32
+         "1wfdyqi64l5x56j259jrrlbh19b7q7i6r83a8q8rjzcqp0kl0vdj"))))
+    (build-system gnu-build-system)
+    ;; TODO: unbundle mkpasswd binary + its po files.
+    (arguments
+     `(#:tests? #f ; Does not exist
+       #:make-flags (list "CC=gcc"
+                          (string-append "prefix=" (assoc-ref %outputs "out")))
+       #:phases
+       (modify-phases %standard-phases
+         (delete 'configure) ; No configure
+         (add-before 'build 'setenv
+           (lambda _
+             (setenv "HAVE_LIBIDN" "1"))))))
+    (inputs
+     `(("libidn" ,libidn)
+       ("gnu-gettext" ,gnu-gettext)))
+    (native-inputs
+     `(("perl" ,perl)))
+    (synopsis "Improved whois client")
+    (description "This whois client is intelligent and can
+automatically select the appropriate whois server for most queries.
+Because of historic reasons this also includes a software to
+encrypt a password with crypt.")
+    (home-page "http://www.linux.it/~md/software/")
+    (license license:gpl2)))
+
 (define-public wireshark
   (package
     (name "wireshark")
-- 
2.10.1

^ permalink raw reply related	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18  8:04 ` ng0
@ 2016-10-18 13:03   ` Marius Bakke
  2016-10-18 13:50     ` ng0
  2016-10-24 16:52   ` Marius Bakke
  1 sibling, 1 reply; 13+ messages in thread
From: Marius Bakke @ 2016-10-18 13:03 UTC (permalink / raw)
  To: ng0, guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

> * gnu/packages/networking.scm (whois): New variable.

Thanks! This works for me. I have a couple of remarks that can be added
before committing if you agree, no need to send an updated patch.

* The source headers seems to indicate that this is GPL2+.
* The only reference to this program on the home page is a link to
  GitHub, do you think we should use that as home-page?
* Gettext only seems used for building locales and is not referenced at
  runtime, perhaps it should be a native-input?
* The Debian package is built with HAVE_ICONV=1, should we set that too?

Additionally it installs locales, but looks for /usr/share/locale at
runtime. Fixing this would probably require upstream help, I don't want
to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
current version probably works on foreign distros, if nothing else.

Are these changes sensible?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18 13:03   ` Marius Bakke
@ 2016-10-18 13:50     ` ng0
  2016-10-18 15:10       ` Marius Bakke
  2016-10-22 11:24       ` ng0
  0 siblings, 2 replies; 13+ messages in thread
From: ng0 @ 2016-10-18 13:50 UTC (permalink / raw)
  To: Marius Bakke, guix-devel

Marius Bakke <mbakke@fastmail.com> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> * gnu/packages/networking.scm (whois): New variable.
>
> Thanks! This works for me. I have a couple of remarks that can be added
> before committing if you agree, no need to send an updated patch.
>
> * The source headers seems to indicate that this is GPL2+.
> * The only reference to this program on the home page is a link to
>   GitHub, do you think we should use that as home-page?
> * Gettext only seems used for building locales and is not referenced at
>   runtime, perhaps it should be a native-input?

Ok.

> * The Debian package is built with HAVE_ICONV=1, should we set that too?

I can send an updated patch with libiconv in the inputs. This is when
you use a libc which does not provide a (usable) iconv, which is why
Gentoo provides the option to build it with this too. As we are
_currently_ only providing options to do one libc globally this is not
so inmportant. I will even build uclibc-ng (I am working on that) with
an outside iconv because reportedly their iconv is in bad shape.

So with this information, should I send a new patch which adds libiconv
and the build option?

> Additionally it installs locales, but looks for /usr/share/locale at
> runtime. Fixing this would probably require upstream help, I don't want
> to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
> current version probably works on foreign distros, if nothing else.

If you know how to fix it, try to bring it to upstream or include a
patch / substitute phase at our end?

> Are these changes sensible?
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18 13:50     ` ng0
@ 2016-10-18 15:10       ` Marius Bakke
  2016-10-22 11:04         ` ng0
  2016-10-22 11:24       ` ng0
  1 sibling, 1 reply; 13+ messages in thread
From: Marius Bakke @ 2016-10-18 15:10 UTC (permalink / raw)
  To: ng0, guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

>> * The Debian package is built with HAVE_ICONV=1, should we set that too?
>
> I can send an updated patch with libiconv in the inputs. This is when
> you use a libc which does not provide a (usable) iconv, which is why
> Gentoo provides the option to build it with this too. As we are
> _currently_ only providing options to do one libc globally this is not
> so inmportant. I will even build uclibc-ng (I am working on that) with
> an outside iconv because reportedly their iconv is in bad shape.
>
> So with this information, should I send a new patch which adds libiconv
> and the build option?

Since we only support glibc at the moment, I don't think adding a
package for libiconv first is necessary. On the other hand, if it can
cause problems on other libc's, it's nice to use an external one.

IMO adding libiconv as input is something that can be done later, when
there is an actual need for it. I guess there are more packages that
will require it. But I don't really mind either way :)

>> Additionally it installs locales, but looks for /usr/share/locale at
>> runtime. Fixing this would probably require upstream help, I don't want
>> to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
>> current version probably works on foreign distros, if nothing else.
>
> If you know how to fix it, try to bring it to upstream or include a
> patch / substitute phase at our end?

I tried patching whois.c to use the glibc default in the call to
bindtextdomain(3), instead of the LOCALEDIR build option. That almost
worked: it searches the system locales, but also expect to find the
translation files there. I'll see if I can cook up a fix for upstream,
but don't think this should hold back the package.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18 15:10       ` Marius Bakke
@ 2016-10-22 11:04         ` ng0
  0 siblings, 0 replies; 13+ messages in thread
From: ng0 @ 2016-10-22 11:04 UTC (permalink / raw)
  To: Marius Bakke, guix-devel

Marius Bakke <mbakke@fastmail.com> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>>> * The Debian package is built with HAVE_ICONV=1, should we set that too?
>>
>> I can send an updated patch with libiconv in the inputs. This is when
>> you use a libc which does not provide a (usable) iconv, which is why
>> Gentoo provides the option to build it with this too. As we are
>> _currently_ only providing options to do one libc globally this is not
>> so inmportant. I will even build uclibc-ng (I am working on that) with
>> an outside iconv because reportedly their iconv is in bad shape.
>>
>> So with this information, should I send a new patch which adds libiconv
>> and the build option?
>
> Since we only support glibc at the moment, I don't think adding a
> package for libiconv first is necessary. On the other hand, if it can
> cause problems on other libc's, it's nice to use an external one.
>
> IMO adding libiconv as input is something that can be done later, when
> there is an actual need for it. I guess there are more packages that
> will require it. But I don't really mind either way :)
>
>>> Additionally it installs locales, but looks for /usr/share/locale at
>>> runtime. Fixing this would probably require upstream help, I don't want
>>> to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
>>> current version probably works on foreign distros, if nothing else.
>>
>> If you know how to fix it, try to bring it to upstream or include a
>> patch / substitute phase at our end?
>
> I tried patching whois.c to use the glibc default in the call to
> bindtextdomain(3), instead of the LOCALEDIR build option. That almost
> worked: it searches the system locales, but also expect to find the
> translation files there. I'll see if I can cook up a fix for upstream,
> but don't think this should hold back the package.
>

I think we can bundle the patch until it/if gets accepts at all by
upstream.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18 13:50     ` ng0
  2016-10-18 15:10       ` Marius Bakke
@ 2016-10-22 11:24       ` ng0
  2016-10-22 16:09         ` Marius Bakke
  1 sibling, 1 reply; 13+ messages in thread
From: ng0 @ 2016-10-22 11:24 UTC (permalink / raw)
  To: Marius Bakke, guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>> * gnu/packages/networking.scm (whois): New variable.
>>
>> Thanks! This works for me. I have a couple of remarks that can be added
>> before committing if you agree, no need to send an updated patch.
>>
>> * The source headers seems to indicate that this is GPL2+.
>> * The only reference to this program on the home page is a link to
>>   GitHub, do you think we should use that as home-page?
>> * Gettext only seems used for building locales and is not referenced at
>>   runtime, perhaps it should be a native-input?
>
> Ok.
>
>> * The Debian package is built with HAVE_ICONV=1, should we set that too?
>
> I can send an updated patch with libiconv in the inputs. This is when
> you use a libc which does not provide a (usable) iconv, which is why
> Gentoo provides the option to build it with this too. As we are
> _currently_ only providing options to do one libc globally this is not
> so inmportant. I will even build uclibc-ng (I am working on that) with
> an outside iconv because reportedly their iconv is in bad shape.

I have my uclibc-ng system not booted: When I specify libiconv in the
inputs, shouldn't it get reported by ldd?

ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
mkpasswd  whois
ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois 
        linux-vdso.so.1 (0x00007ffcd84fe000)
        libidn.so.11 => /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 (0x00007f311084e000)
        libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007f3110638000)
        libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f3110296000)
        /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f3110a81000)
ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd 
        linux-vdso.so.1 (0x00007ffed81c7000)
        libcrypt.so.1 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 (0x00007fc0328e5000)
        libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007fc0326cf000)
        libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc03232d000)
        /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc032b1c000)

> So with this information, should I send a new patch which adds libiconv
> and the build option?
>
>> Additionally it installs locales, but looks for /usr/share/locale at
>> runtime. Fixing this would probably require upstream help, I don't want
>> to hardcode either "/run/current-system/locale" or ~/.guix-profile. The
>> current version probably works on foreign distros, if nothing else.
>
> If you know how to fix it, try to bring it to upstream or include a
> patch / substitute phase at our end?
>
>> Are these changes sensible?
>>
>
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-22 11:24       ` ng0
@ 2016-10-22 16:09         ` Marius Bakke
  2016-10-22 18:57           ` ng0
  0 siblings, 1 reply; 13+ messages in thread
From: Marius Bakke @ 2016-10-22 16:09 UTC (permalink / raw)
  To: ng0, guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:


> I have my uclibc-ng system not booted: When I specify libiconv in the
> inputs, shouldn't it get reported by ldd?
>
> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
> mkpasswd  whois
> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois 
>         linux-vdso.so.1 (0x00007ffcd84fe000)
>         libidn.so.11 => /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 (0x00007f311084e000)
>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007f3110638000)
>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f3110296000)
>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f3110a81000)
> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd 
>         linux-vdso.so.1 (0x00007ffed81c7000)
>         libcrypt.so.1 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 (0x00007fc0328e5000)
>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007fc0326cf000)
>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc03232d000)
>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc032b1c000)

I'm guessing it silently picks the glibc one. FWIW the Gentoo ebuild
does the same thing. Does uclibc-ng provide an iconv interface at all?
Maybe it can be circumvented by having [libc implementation] propagate
libiconv, instead of adding it as a direct input to packages.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-22 16:09         ` Marius Bakke
@ 2016-10-22 18:57           ` ng0
  2016-10-22 19:21             ` Marius Bakke
  0 siblings, 1 reply; 13+ messages in thread
From: ng0 @ 2016-10-22 18:57 UTC (permalink / raw)
  To: Marius Bakke, guix-devel

Marius Bakke <mbakke@fastmail.com> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>
>> I have my uclibc-ng system not booted: When I specify libiconv in the
>> inputs, shouldn't it get reported by ldd?
>>
>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
>> mkpasswd  whois
>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois 
>>         linux-vdso.so.1 (0x00007ffcd84fe000)
>>         libidn.so.11 => /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 (0x00007f311084e000)
>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007f3110638000)
>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f3110296000)
>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f3110a81000)
>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd 
>>         linux-vdso.so.1 (0x00007ffed81c7000)
>>         libcrypt.so.1 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 (0x00007fc0328e5000)
>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007fc0326cf000)
>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc03232d000)
>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc032b1c000)
>
> I'm guessing it silently picks the glibc one. FWIW the Gentoo ebuild
> does the same thing.

That is if your toolchain is glibc based. I have no uclibc-ng or musl
gentoo system at the moment to check this.

> Does uclibc-ng provide an iconv interface at all?

Yes, but so far I wasn't able to get a response by the hardened project
to get a comment on their "the iconv of uclibc and uclibc-ng is horrible
at the moment" comment.. so I'll ask on gentoo-dev list about this, irc
didn't work.

> Maybe it can be circumvented by having [libc implementation] propagate
> libiconv, instead of adding it as a direct input to packages.

Possibly. I'm not yet at the point where I can build a system I like
with this.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-22 18:57           ` ng0
@ 2016-10-22 19:21             ` Marius Bakke
  2016-10-22 19:28               ` ng0
  0 siblings, 1 reply; 13+ messages in thread
From: Marius Bakke @ 2016-10-22 19:21 UTC (permalink / raw)
  To: ng0, guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>
>>
>>> I have my uclibc-ng system not booted: When I specify libiconv in the
>>> inputs, shouldn't it get reported by ldd?
>>>
>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
>>> mkpasswd  whois
>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois 
>>>         linux-vdso.so.1 (0x00007ffcd84fe000)
>>>         libidn.so.11 => /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 (0x00007f311084e000)
>>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007f3110638000)
>>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f3110296000)
>>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f3110a81000)
>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd 
>>>         linux-vdso.so.1 (0x00007ffed81c7000)
>>>         libcrypt.so.1 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 (0x00007fc0328e5000)
>>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007fc0326cf000)
>>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc03232d000)
>>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc032b1c000)
>>
>> I'm guessing it silently picks the glibc one. FWIW the Gentoo ebuild
>> does the same thing.
>
> That is if your toolchain is glibc based. I have no uclibc-ng or musl
> gentoo system at the moment to check this.
>
>> Does uclibc-ng provide an iconv interface at all?
>
> Yes, but so far I wasn't able to get a response by the hardened project
> to get a comment on their "the iconv of uclibc and uclibc-ng is horrible
> at the moment" comment.. so I'll ask on gentoo-dev list about this, irc
> didn't work.
>
>> Maybe it can be circumvented by having [libc implementation] propagate
>> libiconv, instead of adding it as a direct input to packages.
>
> Possibly. I'm not yet at the point where I can build a system I like
> with this.

I'm happy to commit this package now with the changes mentioned earlier,
if that's okay with you. Making it use an external iconv library feels
like "premature optimization", since it works fine with what we have.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-22 19:21             ` Marius Bakke
@ 2016-10-22 19:28               ` ng0
  0 siblings, 0 replies; 13+ messages in thread
From: ng0 @ 2016-10-22 19:28 UTC (permalink / raw)
  To: Marius Bakke, guix-devel

Marius Bakke <mbakke@fastmail.com> writes:

> ng0 <ng0@we.make.ritual.n0.is> writes:
>
>> Marius Bakke <mbakke@fastmail.com> writes:
>>
>>> ng0 <ng0@we.make.ritual.n0.is> writes:
>>>
>>>
>>>> I have my uclibc-ng system not booted: When I specify libiconv in the
>>>> inputs, shouldn't it get reported by ldd?
>>>>
>>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ls
>>>> mkpasswd  whois
>>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd whois 
>>>>         linux-vdso.so.1 (0x00007ffcd84fe000)
>>>>         libidn.so.11 => /gnu/store/sbj1kgn8bs91bn7ba9qk4n3l2rr7dxbr-libidn-1.32/lib/libidn.so.11 (0x00007f311084e000)
>>>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007f3110638000)
>>>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007f3110296000)
>>>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f3110a81000)
>>>> ng0@shadowwalker /gnu/store/fkkvgiqa0x01j6cxipddmn7k20hax1xn-whois-5.2.12/bin$ ldd mkpasswd 
>>>>         linux-vdso.so.1 (0x00007ffed81c7000)
>>>>         libcrypt.so.1 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libcrypt.so.1 (0x00007fc0328e5000)
>>>>         libgcc_s.so.1 => /gnu/store/9nifwk709wajpyfwa0jzaa3p6mf10vxs-gcc-4.9.3-lib/lib/libgcc_s.so.1 (0x00007fc0326cf000)
>>>>         libc.so.6 => /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/libc.so.6 (0x00007fc03232d000)
>>>>         /gnu/store/m9vxvhdj691bq1f85lpflvnhcvrdilih-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007fc032b1c000)
>>>
>>> I'm guessing it silently picks the glibc one. FWIW the Gentoo ebuild
>>> does the same thing.
>>
>> That is if your toolchain is glibc based. I have no uclibc-ng or musl
>> gentoo system at the moment to check this.
>>
>>> Does uclibc-ng provide an iconv interface at all?
>>
>> Yes, but so far I wasn't able to get a response by the hardened project
>> to get a comment on their "the iconv of uclibc and uclibc-ng is horrible
>> at the moment" comment.. so I'll ask on gentoo-dev list about this, irc
>> didn't work.
>>
>>> Maybe it can be circumvented by having [libc implementation] propagate
>>> libiconv, instead of adding it as a direct input to packages.
>>
>> Possibly. I'm not yet at the point where I can build a system I like
>> with this.
>
> I'm happy to commit this package now with the changes mentioned earlier,
> if that's okay with you. Making it use an external iconv library feels
> like "premature optimization", since it works fine with what we have.

Yes, okay for me.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18  8:04 ` ng0
  2016-10-18 13:03   ` Marius Bakke
@ 2016-10-24 16:52   ` Marius Bakke
  1 sibling, 0 replies; 13+ messages in thread
From: Marius Bakke @ 2016-10-24 16:52 UTC (permalink / raw)
  To: ng0, guix-devel

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

ng0 <ng0@we.make.ritual.n0.is> writes:

> * gnu/packages/networking.scm (whois): New variable.

I pushed the updated version of this as
9c798f9036d2d3f90e567052efb06b269c08ed14 with a minor modification to
the description.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 454 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] gnu: Add whois.
  2016-10-18  8:04 [PATCH] gnu: Add whois ng0
  2016-10-18  8:04 ` ng0
@ 2017-01-04 17:41 ` ng0
  1 sibling, 0 replies; 13+ messages in thread
From: ng0 @ 2017-01-04 17:41 UTC (permalink / raw)
  To: guix-devel

ng0 <ng0@we.make.ritual.n0.is> writes:

> For "historic" reasons this also bundles mkpasswd to encrypt passwords.
> I don't want to unbundle this right now, this should be a job for upstream.

Should we provide the "mkpasswd" binary in its own output?

I will submit a small patch.

> PPoint is: A whois client for guix. We have no whois right now. Well that is if
> you see the very limited one of bind as a client, then we do have one.
>
> whois hackint.eu worked (the bind one just tells you "i don't know .eu what is .eu ..."),
> so I assume it is functional.
>
>
>

-- 
♥Ⓐ  ng0
PGP keys and more: https://n0is.noblogs.org/ http://ng0.chaosnet.org

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-01-04 17:41 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-18  8:04 [PATCH] gnu: Add whois ng0
2016-10-18  8:04 ` ng0
2016-10-18 13:03   ` Marius Bakke
2016-10-18 13:50     ` ng0
2016-10-18 15:10       ` Marius Bakke
2016-10-22 11:04         ` ng0
2016-10-22 11:24       ` ng0
2016-10-22 16:09         ` Marius Bakke
2016-10-22 18:57           ` ng0
2016-10-22 19:21             ` Marius Bakke
2016-10-22 19:28               ` ng0
2016-10-24 16:52   ` Marius Bakke
2017-01-04 17:41 ` ng0

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).