bug#36498: modem["ttyUSB0"]: error starting PPP: Could not find "pppd" binary

[pelzflorian (Florian Pelz)]

On Thu, Jul 04, 2019 at 06:08:55PM +0200, pelzflorian (Florian Pelz) wrote:
> On Thu, Jul 04, 2019 at 04:46:32PM +0200, pelzflorian (Florian Pelz) wrote:
> > (git
> reset --hard master, then git am this-new-patch and reconfigure.)
>

Sorry, I meant to write `git reset --hard master^` with a ^ to get rid
of the previous patch.

I would be much obliged if you could test, because my modem works
without NetworkManager needing to find pppd.

Regards,
Florian

bug#36498: modem["ttyUSB0"]: error starting PPP: Could not find "pppd" binary

[pelzflorian (Florian Pelz)]

On Thu, Jul 04, 2019 at 04:46:32PM +0200, pelzflorian (Florian Pelz) wrote:
> I suppose the attached patch could help.  It builds, but I could not
> test.
> 
> Adam, could you try it?  Just follow the Guix manual’s instructions on
> Contributing and `git am the-attached-patch`.
> 

Only if ./pre-inst-env guix system reconfigure with the patch before
is not sufficient, could you try the one attached here instead?  (git
reset --hard master, then git am this-new-patch and reconfigure.)

Regards,
Florian
>From 6eea4f17af471a85dd89adce3acb895fc0fd341f Mon Sep 17 00:00:00 2001
From: Florian Pelz 
Date: Thu, 4 Jul 2019 17:56:34 +0200
Subject: [PATCH] gnu: network-manager: Add ppp input, configure flag and
 substitute to use it.

* gnu/packages/gnome.scm (network-manager): Add them.
---
 gnu/packages/gnome.scm | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index 2820be0022..9ab0d15df6 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -5313,6 +5313,9 @@ users.")
(("systemd") "elogind"))
  (substitute* "./src/nm-logging.c"
(("systemd") "elogind"))
+ (substitute* "src/ppp/nm-ppp-manager.c"
+   (("nm_utils_find_helper \\(\"pppd\".*")
+"PPPD_PATH;"))
  #t
 (build-system gnu-build-system)
 (outputs '("out"
@@ -5322,7 +5325,9 @@ users.")
(let ((out  (assoc-ref %outputs "out"))
  (doc  (assoc-ref %outputs "doc"))
  (dhclient (string-append (assoc-ref %build-inputs "isc-dhcp")
-  "/sbin/dhclient")))
+  "/sbin/dhclient"))
+ (pppd (string-append (assoc-ref %build-inputs "ppp")
+  "/sbin/pppd")))
  (list "--with-systemd-logind=yes" ;In Guix System, this is provided 
by elogind.
"--with-consolekit=no"
"--with-crypto=gnutls"
@@ -5335,7 +5340,8 @@ users.")
   out "/etc/dbus-1/system.d")
(string-append "--with-html-dir="
   doc "/share/gtk-doc/html")
-   (string-append "--with-dhclient=" dhclient)))
+   (string-append "--with-dhclient=" dhclient)
+   (string-append "--with-pppd=" pppd)))
#:phases
(modify-phases %standard-phases
  (add-before 'configure 'pre-configure
@@ -5395,6 +5401,7 @@ users.")
("libxslt" ,libxslt)
("libxml2" ,libxml2)
("pkg-config" ,pkg-config)
+   ("ppp" ,ppp)
;; For testing.
("python" ,python-wrapper)
("python-dbus" ,python-dbus)
-- 
2.22.0

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Ludovic Courtès]

Hello,

Robert Vollmert  skribis:

>> On 4. Jul 2019, at 09:59, Ludovic Courtès  wrote:
>> 
>> Hi,
>> 
>> “Impossible” is an exaggeration, but when you source the
>> ‘environment-variables’ file, for example, PWD and other variables will
>> refer to /tmp/guix-build-….drv, which won’t exist.  Likewise, generated
>> files such as Makefiles would have captured the ….drv name.
>
> But, wait, won’t they refer to /tmp/guix-build-0.drv? So debugging a build
> from /tmp/guix-build-1.drv will use a mix of both directories?

As the manual explains, the name inside the container is fixed, it’s
always .drv-0; the name outside may vary to avoid naming collisions or
as a consequence of setting TMPDIR.

>> Like Mark writes, it’s not the end of the world: you can simply rename
>> /tmp/guix-build-….drv-0 to /tmp/guix-build-….drv.  However, it means
>> that things would be inconvenient by default, which doesn’t sound great
>> to me.
>> 
>> WDYT?
>
> I don't particularly care anymore. I think it’s a confusing mess, but for
> myself I’ve learnt this wart and won’t run into the problem anymore.

I understand this has been a confusing experience, but I can’t really
think of any other sensible way to approach it.

Anyway, closing it now.  Thank you!

Ludo’.

bug#36498: modem["ttyUSB0"]: error starting PPP: Could not find "pppd" binary

[pelzflorian (Florian Pelz)]

On Thu, Jul 04, 2019 at 03:48:11PM +0200, Adam Mazurkiewicz wrote:
> I am geeting the error
> 
> modem["ttyUSB0"]: error starting PPP: Could not find "pppd" binary
> 
> when choosing a modem connection i nm.
> 
> Here you are details:
> 
> s@s:~$ cat ~/Dropbox/Guix/export/txt/grep1
> Jul  4 14:50:04 localhost ModemManager[419]:   (ttyUSB0): port
> attributes not fully set
> Jul  4 14:50:04 localhost ModemManager[419]:   (ttyUSB1): port
> attributes not fully set
> Jul  4 14:50:07 localhost ModemManager[419]:   (ttyUSB1): port
> attributes not fully set
> Jul  4 14:50:13 localhost ModemManager[419]:   Could not grab
> port (usbmisc/cdc-wdm2): 'Cannot add port 'usbmisc/cdc-wdm2',
> unsupported'
> Jul  4 14:50:13 localhost ModemManager[419]:   (ttyUSB0): port
> attributes not fully set
> Jul  4 14:50:17 localhost ModemManager[419]:   couldn't load
> list of Own Numbers: 'Not found'
> Jul  4 14:50:18 localhost ModemManager[419]:   (ttyUSB0): port
> attributes not fully set
> Jul  4 14:50:41 localhost ModemManager[419]:   (ttyUSB1): port
> attributes not fully set
> Jul  4 14:50:41 localhost NetworkManager[325]: 
> [1562244641.5798] device (ttyUSB0): ip-ifname: set ifname 'ttyUSB1',
> unknown ifindex
> Jul  4 14:50:41 localhost NetworkManager[325]: 
> [1562244641.5806] device (ttyUSB0): interface ttyUSB1 not up for IP
> configuration
> Jul  4 14:50:41 localhost NetworkManager[325]: 
> [1562244641.5826] modem["ttyUSB0"]: error starting PPP: Could not find
> "pppd" binary
> Jul  4 14:50:41 localhost NetworkManager[325]: 
> [1562244641.5838] device (ttyUSB0): Activation: failed for connection
> 'Orange Standard access - with image compression'
> Jul  4 14:50:42 localhost ModemManager[419]:   (ttyUSB1): port
> attributes not fully set
> s@s:~$
> 
> s@s:~$ cat ~/Dropbox/Guix/export/txt/messages
> (...)
> Jul  4 14:50:03 localhost shepherd[1]: Service xorg-server has been started.
> Jul  4 14:50:03 localhost vmunix: [4.581161] option 1-2:1.0: GSM
> modem (1-port) converter detected
> Jul  4 14:50:03 localhost vmunix: [4.589076] usb 1-2: GSM modem
> (1-port) converter now attached to ttyUSB0
> Jul  4 14:50:03 localhost vmunix: [4.589145] option 1-2:1.1: GSM
> modem (1-port) converter detected
> Jul  4 14:50:03 localhost vmunix: [4.589235] usb 1-2: GSM modem
> (1-port) converter now attached to ttyUSB1
> Jul  4 14:50:03 localhost vmunix: [4.618852] kvm: disabled by bios
> Jul  4 14:50:03 localhost vmunix: [4.622803] intel_powerclamp: No
> package C-state available
> Jul  4 14:50:03 localhost vmunix: [4.643252] sr 7:0:0:0: [sr0]
> tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jul  4 14:50:03 localhost vmunix: [4.643256] sr 7:0:0:0: [sr0]
> tag#0 Sense Key : Medium Error [current]
> Jul  4 14:50:03 localhost vmunix: [4.643258] sr 7:0:0:0: [sr0]
> tag#0 Add. Sense: Unrecovered read error
> Jul  4 14:50:03 localhost vmunix: [4.643262] sr 7:0:0:0: [sr0]
> tag#0 CDB: Read(10) 28 00 00 00 8c 80 00 00 3c 00
> Jul  4 14:50:03 localhost vmunix: [4.643264] print_req_error:
> critical medium error, dev sr0, sector 143872 flags 80700
> Jul  4 14:50:03 localhost vmunix: [4.681836] r8169 :02:00.0
> enp2s0: renamed from eth0
> Jul  4 14:50:03 localhost vmunix: [4.683250] random: crng init done
> Jul  4 14:50:03 localhost vmunix: [4.683253] random: 7 urandom
> warning(s) missed due to ratelimiting
> Jul  4 14:50:02 localhost avahi-daemon[332]: Loading service file
> /services/sftp-ssh.service.
> Jul  4 14:50:03 localhost vmunix: [4.689711] lm90 3-004c: 3-004c
> supply vcc not found, using dummy regulator
> Jul  4 14:50:03 localhost vmunix: [4.690028] huawei_cdc_ncm
> 1-2:1.2: resetting NTB format to 16-bit
> Jul  4 14:50:03 localhost vmunix: [4.690068] gpio_ich
> gpio_ich.1.auto: GPIO from 451 to 511
> Jul  4 14:50:03 localhost vmunix: [4.690368] huawei_cdc_ncm
> 1-2:1.2: MAC-Address: 00:1e:10:1f:00:00
> Jul  4 14:50:03 localhost vmunix: [4.690371] huawei_cdc_ncm
> 1-2:1.2: setting rx_max = 16384
> Jul  4 14:50:03 localhost vmunix: [4.691083] iTCO_vendor_support:
> vendor-support=0
> Jul  4 14:50:03 localhost vmunix: [4.693305] iTCO_wdt: Intel TCO
> WatchDog Timer Driver v1.11
> Jul  4 14:50:03 localhost vmunix: [4.693345] iTCO_wdt: Found a
> ICH9R TCO device (Version=2, TCOBASE=0x0860)
> Jul  4 14:50:03 localhost vmunix: [4.694250] iTCO_wdt:
> initialized. heartbeat=30 sec (nowayout=0)
> Jul  4 14:50:03 localhost vmunix: [4.697758] huawei_cdc_ncm
> 1-2:1.2: NDP will be placed at end of frame for this device.
> Jul  4 14:50:03 localhost vmunix: [4.697832] huawei_cdc_ncm
> 1-2:1.2: cdc-wdm2: USB WDM device
> Jul  4 14:50:03 localhost vmunix: [4.697874] sr 7:0:0:0: [sr0]
> tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> Jul  4 14:50:03 localhost vmunix: [4.697877] sr 7:0:0:0: [sr0]
> tag#0 Sense Key : Medium Error [current]
> Jul  4 14:50:02 localhost dbus-daemon[322]: [system] Activating
> 

bug#36330: guix-build-branch.sh failed on Fedora 29

[Matt Wette]

On 7/4/19 2:29 AM, Ludovic Courtès wrote:

Hi Matt,

Matt Wette  skribis:


write(2, "updating checkout of 
'https://notabug.org/cwebber/guile-gcrypt.git'...\n", 71) = 71
openat(AT_FDCWD, "/usr/lib64/libgit2.la", O_RDONLY) = -1 ENOENT (No such file 
or directory)

It seems that your installation of Guile-Git fails to load libgit2, and
thus doesn’t work at all.  Could you check if that is the case?

(Besides, unless you want to build from source, I’d recommend using the
binary tarball to get Guix set up quickly:
.)



I will look into the binary.  Thanks for taking the time on this.

Matt

bug#36330: guix-build-branch.sh failed on Fedora 29

[Ludovic Courtès]

Hi Matt,

Matt Wette  skribis:

> write(2, "updating checkout of 
> 'https://notabug.org/cwebber/guile-gcrypt.git'...\n", 71) = 71
> openat(AT_FDCWD, "/usr/lib64/libgit2.la", O_RDONLY) = -1 ENOENT (No such file 
> or directory)

It seems that your installation of Guile-Git fails to load libgit2, and
thus doesn’t work at all.  Could you check if that is the case?

(Besides, unless you want to build from source, I’d recommend using the
binary tarball to get Guix set up quickly:
.)

Thanks,
Ludo’.

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Robert Vollmert]

> On 4. Jul 2019, at 09:59, Ludovic Courtès  wrote:
> 
> Hi,
> 
> “Impossible” is an exaggeration, but when you source the
> ‘environment-variables’ file, for example, PWD and other variables will
> refer to /tmp/guix-build-….drv, which won’t exist.  Likewise, generated
> files such as Makefiles would have captured the ….drv name.

But, wait, won’t they refer to /tmp/guix-build-0.drv? So debugging a build
from /tmp/guix-build-1.drv will use a mix of both directories?

> Like Mark writes, it’s not the end of the world: you can simply rename
> /tmp/guix-build-….drv-0 to /tmp/guix-build-….drv.  However, it means
> that things would be inconvenient by default, which doesn’t sound great
> to me.
> 
> WDYT?

I don't particularly care anymore. I think it’s a confusing mess, but for
myself I’ve learnt this wart and won’t run into the problem anymore.

Cheers
Robert

bug#36443: Canonicalized build directory name in container leads to confusion (was guix build mixes build dirs?)

[Ludovic Courtès]

Hi,

Robert Vollmert  skribis:

>> On 2. Jul 2019, at 15:37, Ludovic Courtès  wrote:
>> 
>>> /* In a sandbox, for determinism, always use the same temporary
>>>directory. */
>>> -tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" 
>>> + drvName + "-0" : tmpDir;
>>> +tmpDirInSandbox = useChroot ? canonPath("/tmp", true) + "/guix-build-" 
>>> + drvName : tmpDir;
>> 
>> The result would be that the temporary directory would always have a
>> different name inside and outside the container.  Consequently,
>> debugging along the lines of what the manual suggests (info "(guix)
>> Debugging Build Failures") would become pretty much impossible.
>
> Why do you think it would become impossible?

“Impossible” is an exaggeration, but when you source the
‘environment-variables’ file, for example, PWD and other variables will
refer to /tmp/guix-build-….drv, which won’t exist.  Likewise, generated
files such as Makefiles would have captured the ….drv name.

Like Mark writes, it’s not the end of the world: you can simply rename
/tmp/guix-build-….drv-0 to /tmp/guix-build-….drv.  However, it means
that things would be inconvenient by default, which doesn’t sound great
to me.

WDYT?

Thanks,
Ludo’.