Bug#872178: Status of debconf translation handling in nodm, help needed?
Hello Mike, On Sat, Dec 15, 2018 at 09:09:18AM +, Mike Gabriel wrote: > On Saturday, 15 December 2018, Helge Kreutzmann wrote: > > Hello Mike, > > hello Ondřej, > > On Wed, Nov 14, 2018 at 02:33:27PM +0100, Helge Kreutzmann wrote: > > > your package nodm has several unhandled debconf > > > translations, some of then available for several months. I see that > > > several uplaods have been made, is there a reason for not including > > > those translations? Do you need help handling? > > > > > > I'm currently trying (also in preparation for the freeze) to resolve > > > those pending translation. In December I will consider if a l10n NMU > > > is appropriate (which I would rather avoid, a MU is much better and of > > > course better integrated in your workflow). > > > > As I haven't got a reply, I will prepare a l10n NMU next week > > considering #872178, #906170 and the lintian warning > > priority-extra-is-replaced-by-priority-optional > > > > I also will look at #852125, the fix looks rather straightforward to > > integrate. > > > > If you want to do a MU (preferred) let me know. > > > > Greetings > > > > Helge > > Please push your changes to the packaging repo on > salsa.debian.org/debian/nodm. I will do the maintainer upload once you ping > me... Thanks. Can you grant me write access then? Currently I'm not allowed to push to the repository. Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ signature.asc Description: Digital signature
Bug#916513: inxi -C -xxx doesn't show information about AVX, AVX2, etc
Package: inxi Version: 3.0.29-1-1 Severity: normal $ inxi -C - CPU: Topology: 16-Core (2-Die) model: AMD Ryzen Threadripper 2950X bits: 64 type: MT MCP MCM arch: Zen+ rev: 2 L2 cache: 8192 KiB flags: lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 223979 Speed: 4114 MHz min/max: 2200/3500 MHz boost: enabled Core speeds (MHz): 1: 2820 2: 3354 3: 3002 4: 2559 5: 4177 6: 4238 7: 3359 8: 3709 9: 2401 10: 2388 11: 2404 12: 2597 13: 2806 14: 2719 15: 3692 16: 2425 17: 2406 18: 2390 19: 2395 20: 2559 21: 2442 22: 2380 23: 2384 24: 3109 25: 2755 26: 2443 27: 2598 28: 2435 29: 2429 30: 2736 31: 2486 $ $ grep flags /proc/cpuinfo | head -1 flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca $ $ lscpu | grep Flags Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb hw_pstate sme ssbd sev ibpb vmmcall fsgsbase bmi1 avx2 smep bmi2 rdseed adx smap clflushopt sha_ni xsaveopt xsavec xgetbv1 xsaves clzero irperf xsaveerptr arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov succor smca $ $ cpuid --one-cpu | grep -i AVX AVX: advanced vector extensions = true AVX2: advanced vector extensions 2 = true AVX512F: AVX-512 foundation instructions = false AVX512DQ: double & quadword instructions = false AVX512IFMA: fused multiply add = false AVX512PF: prefetch instructions = false AVX512ER: exponent & reciprocal instrs = false AVX512CD: conflict detection instrs = false AVX512BW: byte & word instructions = false AVX512VL: vector length = false AVX512VBMI: vector byte manipulation = false AVX512_VBMI2 = false AVX512_VNNI = false AVX512_BITALG: bit count/shiffle = false AVX512: VPOPCNTDQ instruction= false AVX512_4VNNIW: neural network instrs = false AVX512_4FMAPS: multiply acc single prec = false XCR0 supported: AVX state= true XCR0 supported: AVX-512 opmask = false XCR0 supported: AVX-512 ZMM_Hi256= false XCR0 supported: AVX-512 Hi16_ZMM = false AVX/YMM features (0xd/2): AVX/YMM save state byte size = 0x0100 (256) AVX/YMM save state byte offset = 0x0240 (576) $ Best regards, Witold -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/32 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages inxi depends on: ii pciutils 1:3.5.2-1 ii procps2:3.3.15-2 Versions of packages inxi recommends: ii dmidecode 3.2-1 ii dnsutils 1:9.11.5+dfsg-1 ii file 1:5.34-2 ii hddtemp0.3-beta15-53 ii iproute2 4.18.0-2 ii kmod 25-1 ii lm-sensors 1:3.4.0-4 ii mesa-utils 8.4.0-1 ii net-tools 1.60+git20180626.aebd88e-1 ii sudo 1.8.23-2 ii tree 1.7.0-5 ii usbutils 1:007-4+b1 ii x11-utils 7.7+4 ii x11-xserver-utils 7.7+8 Versions of packages inxi suggests: ii curl 7.61.0-1 pn libcpanel-json-xs-perl | libjson-xs-perl pn libxml-dumper-perl ii perl [libhttp-tiny-perl] 5.28.0-3
Bug#916512: add PO/GETTEXT support to .desktop
Package: im-config Version: 0.38-1 Severity: wishlist I don't want to loose this ... | Hi i have just translated im-config. | | But the strings for the .desktop file does not seem to be on | https://translations.launchpad.net/ubuntu/+source/im-config | | Can you add the strings for the .desktop file to the po file so its easier to | translate? | | Name=Input Method | Comment=Set Keyboard Input Method | | If not can you add this to the .desktop file for me? | | Name[da]=Inputmetode | Comment[da]=Indstil inputmetode for tastatur Data is committed to devel branch but it will be nice this is also addressed in build system properly. Osamu -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (10, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages im-config depends on: ii gettext-base 0.19.8.1-9 Versions of packages im-config recommends: ii whiptail0.52.20-8 ii x11-common 1:7.7+19 ii zenity 3.30.0-1 im-config suggests no packages. -- no debconf information
Bug#886291: pycryptodome: python3-pycryptodome contains pycryptodomex instead of pycryptodome
Hi, Have you got a chance to check the PR [0] ? The python transition is done now, but I'm not sure we have the time to complete pycryptodomex and pycrytodome transition before the freeze. (Or the transition freeze is only blocking any new transition ?) What do you think ? [0] https://salsa.debian.org/python-team/modules/pycryptodome/merge_requests/1 Thanks :) -- Alexis Murzeau PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F signature.asc Description: OpenPGP digital signature
Bug#872178: Status of debconf translation handling in nodm, help needed?
Hi Helge, On Saturday, 15 December 2018, Helge Kreutzmann wrote: > Hello Mike, > hello Ondřej, > On Wed, Nov 14, 2018 at 02:33:27PM +0100, Helge Kreutzmann wrote: > > your package nodm has several unhandled debconf > > translations, some of then available for several months. I see that > > several uplaods have been made, is there a reason for not including > > those translations? Do you need help handling? > > > > I'm currently trying (also in preparation for the freeze) to resolve > > those pending translation. In December I will consider if a l10n NMU > > is appropriate (which I would rather avoid, a MU is much better and of > > course better integrated in your workflow). > > As I haven't got a reply, I will prepare a l10n NMU next week > considering #872178, #906170 and the lintian warning > priority-extra-is-replaced-by-priority-optional > > I also will look at #852125, the fix looks rather straightforward to > integrate. > > If you want to do a MU (preferred) let me know. > > Greetings > > Helge Please push your changes to the packaging repo on salsa.debian.org/debian/nodm. I will do the maintainer upload once you ping me... Mike -- Sent from my Jolla
Bug#915759: gitlab 11.5.3+dfsg-1 is in the archive now
Control: fixed -1 gitlab/11.5.3+dfsg-1 Closing this bug. signature.asc Description: OpenPGP digital signature
Bug#915547: ibus: IBus only knows about major languages (i.e. those with iso639-2 codes)
On Wed, Dec 5, 2018 at 10:45 AM Daniel Glassey wrote: > On Wed, Dec 5, 2018 at 10:23 AM Osamu Aoki wrote: > >> I suppose this is fixed for Debian thanks to Yang > > Hi, Does anyone have any thoughts about the patch? > Did you propose this to upstream too？ >> > > I made a PR(2061). I just created a github issue upstream about it > too(2062) > Update: My interaction with upstream is at https://github.com/ibus/ibus/issues/2064 My understanding is that he will be willing to accept the change if I do the extra work to use the iso639-3.json file instead of the xml because the xml files are deprecated. Would you prefer for me to do that before accepting the patch for Debian? Regards, Daniel > > 2018/12/05 1:12、Daniel Glassey のメール: >> >> > Source: ibus >> > Severity: normal >> > Tags: patch >> > >> > Dear Team, >> > >> > IBus parses the iso-codes iso_639-2.xml file to get the name of >> languages that IBus engines >> > support. That has under 500 languages. >> > >> > The iso639-3.xml file has codes and names for the known languages at >> its time of publication. >> > >> > Keyman (www.keyman.com) already has support for over 1000 languages, >> many of which are only named >> > in iso639-3. At the moment they are all grouped under "Other". >> > >> > Other engines such as m17n may support some of these languages too. >> > >> > I'm attaching a patch to use iso639-3 instead of iso639-2 >> > I've made a PR for it upstream at >> https://github.com/ibus/ibus/pull/2061 >> > >> > Regards, >> > Daniel >> > >> > -- System Information: >> > Debian Release: buster/sid >> > APT prefers testing >> > APT policy: (500, 'testing') >> > Architecture: amd64 (x86_64) >> > >> > Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores) >> > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), >> LANGUAGE=en_GB:en (charmap=UTF-8) >> > Shell: /bin/sh linked to /bin/dash >> > Init: systemd (via /run/systemd/system) >> > LSM: AppArmor: enabled >> > >> >
Bug#860264: ifquery behaviour
# grep auto /etc/network/interfaces auto lo # grep hotplug /etc/network/interfaces allow-hotplug enp0s31f6 # ifquery --read-environment --list --exclude=lo # as in unit file # # ifquery --read-environment --list --exclude=lo --allow auto # # ifquery --read-environment --list --exclude=lo --allow hotplug enp0s31f6 But if I convert enp0s31f6 to auto # grep /etc/network/interfaces auto lo auto enp0s31f6 # ifquery --read-environment --list --exclude=lo --allow hotplug # (as expected) # ifquery --read-environment --list --exclude=lo --allow auto enp0s31f6 # ifquery --read-environment --list --exclude=lo enp0s31f6 So with the interface set to auto, the ifquery in the unit file picks it up. With the interface set to allow-hotplug, it doesn't. I think this is part of the puzzle, but there is more to it. I think that there are some issues arising from how ifupdown and systemd (fail to) communicate about when exactly the network interface is fully up and working (particularly in the dhcp case). If you look at the work that has gone into ifupdown since the stretch release, it seems like there are some issues there that have now, hopefully, been resolved. Kind regards Vince
Bug#909550: possible conflict over the /usr/bin/ia namespace
[Adding ftpmas...@debian.org to CC] Hi Antoine et al., > So anyways - irl will upload a new package now, presumably -2 or more, > so i think << 0.242+git20151019-2~ is fine. I just went to process this package in NEW but this new upload does not appear to have happened yet. Is that correct? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#915925: libxfce4util: Uses vendor-specific patch series file (ubuntu.series)
Hi, On Thu, Dec 13, 2018 at 10:37:38PM +0100, Chris Lamb wrote: > > > Please migrate away from such series files and consider alternatives > > > such differing source packages or modify the build process to behave > > > conditionally or to conditionally patch files explicitly. > […] > > is there a documented way to actually do that in a simple/maintainable way > > I'm not aware of a documented way that matches this description, alas. Indeed, the ctte decision didn't provide any migration path. > I've had some brief discussions with in Mattia (CC'd) that might be > useful though; he had migrated away from an foo.series in another > package and I had mooted writing a possible "include"-able .mk snippet. I moved avay from foo.series in hexchat. https://salsa.debian.org/debian/hexchat/commit/dd1b936d907d664c0f9e10119778d99228591f60 That thing seems to work correctly, but it's kind of horrible. At least you don't have to distiguish between ubuntu-specific and debian-specific patches. Another way would be to wrap the ubuntu specific code in #ifdef and set that conditionally in d/rules. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#916510: duplicate
Sorry, just noticed that this report duplicates several other reported bugs. But also found a suspected solution elsewhere: https://bugs.freedesktop.org/show_bug.cgi?id=108984 https://bugs.freedesktop.org/show_bug.cgi?id=108850
Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1
Hello, On Wed, Dec 12, 2018 at 05:14:03PM +0100, Uwe Kleine-König wrote: > [ 1057.771583] random: crng init done > [ 1057.774739] random: 7 urandom warning(s) missed due to ratelimiting > > I'm not aware the machine has a random number generator, so the solutions > presented here up to now don't help me. For the record: After just powering on the machine and waiting for the crng to be initialized I once saw the "crng init done" only after 1h40. I now installed haveged and now the time is down to [ 27.490557] random: crng init done which is at least bearable. > I think the idea to mention this in the release notes for buster is a > good one (unless a solution is found until then of course). Maybe openssh should recommend haveged? Best regards Uwe signature.asc Description: PGP signature
Bug#914297: apache2: getrandom call blocks on first startup, systemd kills with timeout
reassign 914297 systemd affects 914297 apache2 thanks On Saturday, 15 December 2018 02:24:54 CET Alexander E. Patrakov wrote: > Stefan Fritsch : > > The rng should be initialized after the seed is loaded from disk. > > This is false according to systemd developers. Its state is changed, > but it is still not initialized, because they think that the seed > might come from a gold master image. That's broken, then. It turns out there was a similar bug against openssh which was closed as wontfix [1]. I don't see how apache can do anything about this, either. But I disagree with the systemd maintainers that there is nothing that systemd can do about this. They should credit the entropy loaded from the seed but save a new seed immediately after reading it during startup, to avoid that the same seed is used more than once. A second (but worse) alternative would be to provide something that waits for the RNG to be initialized that other services can depend on. Cheers, Stefan [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912087
Bug#916511: ITP: ruby-nakayoshi-fork -- solves CoW friendly problem on MRI 2.2 and later
package: wnpp severity: wishlist owner: Pirate Praveen from rubygems.org/gems/nakayoshi_fork dependency of gitlab 11.6.x signature.asc Description: OpenPGP digital signature
Bug#916510: linux-image-4.18.0-3-amd64: Absolutely no video output after i915 module is initialized
Package: src:linux Version: 4.18.20-2 Severity: important The system boots up, everything is OK until the DRM module is loaded. At that time the screen goes black, and there's no going back. Switching to console using Ctrl+F1 / Ctrl+Alt+F1 brings back the text mode screen, but it remains invisible. Not surprised as based on dmesg, the i915 module panics because of a NULL pointer dereference. The system is working, just a "poweroff" command leads to a crash (presumed, as nothing is visible, the HW is not turned off, but does not respond). The GPU is Intel HD Graphics (Ironlake), the "first" generation, integrated in Arrandale, also going by the name GMA5700MHD. linux-image-4.18.0-2-amd64 (4.18.10-2+b1) works like a charm. Relevant log entries of a successful boot with linux-image-4.18.0-2-amd64: [3.458967] [drm] RC6 disabled, disabling runtime PM support [3.461466] [drm] Initialized i915 1.6.0 20180514 for :00:02.0 on minor 0 [3.462212] ACPI: Video Device [VID] (multi-head: yes rom: no post: no) [3.462380] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8 [3.462836] snd_hda_intel :00:1b.0: bound :00:02.0 (ops i915_audio_component_bind_ops [i915]) [3.479630] fbcon: inteldrmfb (fb0) is primary device The dmesg output of linux-image-4.18.0-3-amd64 is attached. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: LENOVO product_name: 3680L55 product_version: ThinkPad X201 chassis_vendor: LENOVO chassis_version: Not Available bios_vendor: LENOVO bios_version: 6QET70WW (1.40 ) board_vendor: LENOVO board_name: 3680L55 board_version: Not Available ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 02) Subsystem: Lenovo Core Processor DRAM Controller [17aa:2193] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] (rev 02) (prog-if 00 [VGA controller]) Subsystem: Lenovo Core Processor Integrated Graphics Controller [17aa:215a] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06) Subsystem: Lenovo 5 Series/3400 Series Chipset HECI Controller [17aa:215f] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: mei_me Kernel modules: mei_me 00:19.0 Ethernet controller [0200]: Intel Corporation 82577LM Gigabit Network Connection [8086:10ea] (rev 06) Subsystem: Lenovo 82577LM Gigabit Network Connection [17aa:2153] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e Kernel modules: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 06) (prog-if 20 [EHCI]) Subsystem: Lenovo 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [17aa:2163] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 06) Subsystem: Lenovo 5 Series/3400 Series Chipset High Definition Audio [17aa:215e] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:1c.3 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 [8086:3b48] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+
Bug#756170: mount option timeo - in deciseconds, or seconds?
I think this report is incorrect.
If you agree, please close it.
If not, please offer some evidence for your belief.
My evidence is below.
I looked in the upstream git of nfs-utils.
The 'deciseconds' has been in there since the start of git history
(2007, commit id 16db99b56a532bf56fa27618a6ef30763cd9006f).
There is no direct use of the 'timeo' field of the NFS data structure
in nfs-utils so we have to look at the kernel code.
In linux/fs/nfs/client.c there is this function
/*
* Initialise the timeout values for a connection
*/
void nfs_init_timeout_values(struct rpc_timeout *to, int proto,
int timeo, int retrans)
{
to->to_initval = timeo * HZ / 10;
...
which is called from this function in the same module
static int nfs_init_server(struct nfs_server *server,
const struct nfs_parsed_mount_data *data,
struct nfs_subversion *nfs_mod)
{
struct rpc_timeout timeparms;
struct nfs_client_initdata cl_init = {
.hostname = data->nfs_server.hostname,
.addr = (const struct sockaddr *)>nfs_server.address,
.addrlen = data->nfs_server.addrlen,
.nfs_mod = nfs_mod,
.proto = data->nfs_server.protocol,
.net = data->net,
.timeparms = ,
};
struct nfs_client *clp;
int error;
nfs_init_timeout_values(, data->nfs_server.protocol,
data->timeo, data->retrans);
if (data->flags & NFS_MOUNT_NORESVPORT)
set_bit(NFS_CS_NORESVPORT, _init.init_flags);
I think this makes it reasonably clear 'timeo' is in deciseconds,
although the manpage could take a few words to explain how it comes
to use that peculiar unit.
Kind regards
Vince
