diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/anatomy_of_a_hurd_system.mdwn | 19 | ||||
| -rw-r--r-- | open_issues/clock_gettime.mdwn | 8 | ||||
| -rw-r--r-- | open_issues/dde.mdwn | 10 | ||||
| -rw-r--r-- | open_issues/debugging_gnumach_startup_qemu_gdb.mdwn | 2 | ||||
| -rw-r--r-- | open_issues/glibc.mdwn | 39 | ||||
| -rw-r--r-- | open_issues/glibc/debian/experimental.mdwn | 9 | ||||
| -rw-r--r-- | open_issues/multithreading.mdwn | 17 | ||||
| -rw-r--r-- | open_issues/nightly_builds_deb_packages.mdwn | 850 | ||||
| -rw-r--r-- | open_issues/performance.mdwn | 19 | ||||
| -rw-r--r-- | open_issues/performance/io_system/read-ahead.mdwn | 10 | ||||
| -rw-r--r-- | open_issues/ti-rpc_then_nfs.mdwn | 27 | ||||
| -rw-r--r-- | open_issues/versioning.mdwn | 5 | ||||
| -rw-r--r-- | open_issues/virtualization/fakeroot.mdwn | 31 |
13 files changed, 1041 insertions, 5 deletions
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 33635b80..932e11a6 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1327,3 +1327,22 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l <teythoon> load it from grub instead of /hurd/ext2fs.static <teythoon> look at the grub config for how this is done <teythoon> let me know if it worked ;) + + +# IRC, freenode, #hurd, 2014-03-04 + + <bwright> Can I run a single instance of hurd on multiple computers + <bwright> With them acting as different servers? + <braunr> no + <bwright> Like the fs server on one pc etc. + <bwright> Which os could I do this with? + <bwright> I assumed Mach RPC would support that. + <braunr> it can + <braunr> but we don't use it that way + <braunr> plan9 is probably better suited to what you want + <braunr> inferno too + <braunr> maybe dragonflybsd + <bwright> Yep. + <bwright> irAwesome. + <bwright> Plan9 is exactly it. + <braunr> enjoy diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index baa21bbb..407a104c 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -338,3 +338,11 @@ In context of [[select]]. anyway :) <desrt> (although it will soon...) <braunr> nice + + +## IRC, freenode, #hurd, 2014-03-05 + + <desrt> braunr: bit of a warning: i released the glib that depends on + working pthread_condattr_setclock(..._MONOTONIC) and pochu said that it + will be landing in debian within the next days + <braunr> desrt: ok diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn index 9d8bf509..e7083557 100644 --- a/open_issues/dde.mdwn +++ b/open_issues/dde.mdwn @@ -614,6 +614,16 @@ In context of [[libpthread]]. <braunr> primitives* +## IRC, freenode, #hurd, 2014-03-08 + + <gg0> what to do if network freezes? + <teythoon> gg0: depends on what caused the freeze + <teythoon> gg0: you could try to kill the netdde process + <gg0> it's just apt-get'ing, download phase + <braunr> yess kill netdde + <braunr> there are known deadlocks in netdde + + # IRC, freenode, #hurd, 2012-08-18 <braunr> hm looks like if netdde crashes, the kernel doesn't handle it diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn index 7b300ea1..a9743608 100644 --- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -131,7 +131,7 @@ License|/fdl]]."]]"""]] at least -# Multiboot +# <a name="multiboot">Multiboot</a> See also discussion about *multiboot* on [[arm_port]]. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 4dad229f..ad7b3c72 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -1855,6 +1855,45 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 <braunr> teythoon: i think it should be in glibc <braunr> maybe in mach/ + * POSIX record locking + + IRC, freenode, #hurd, 2014-02-27: + + <azeem_> tschwinge: schould POSIX record locking be on + http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#missing + as well. or is that strictly a Hurd thing? (I don't remember) + <tschwinge> azeem_: Neither do I :-), but I'll have a look later + on. + + * <a name="execve_relative_paths">`execve` with relative paths</a> + + [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id + "4BFA500A.7030502@gmail.com"]]. + + IRC, freenode, #hurd, 2014-03-05: + + <teythoon> youpi: what about the exec_filename patch series? [...] + <youpi> Roland was disagreeing with it + + * <a name="mount">`mount`/`umount`</a> + + IRC, freenode, #hurd, 2014-03-01: + + <gnu_srs1> Hi, how to handle packages depending on mount.h, et al? + On Hurd mount/umount is supplied by hurd is not in libc? + <azeem> gnu_srs1: mount or mount.h? + <gnu_srs1> mount.h et al + <gnu_srs1> man 2 mount + <azeem> what is the question then? + <gnu_srs1> some packages expect the mount 2 functionality + available, not by the external command mount/umonut + <gnu_srs1> umount* + <gnu_srs1> azeem: one example is fuse + <teythoon> gnu_srs1: that is correct + <teythoon> gnu_srs1: i put a small hacks entry in the list about + moving the mount/umount functionality from our utilities to the + libc + For specific packages: * <a id=octave>[[octave]]</a> diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn index 273f02fd..4ae9807b 100644 --- a/open_issues/glibc/debian/experimental.mdwn +++ b/open_issues/glibc/debian/experimental.mdwn @@ -225,6 +225,15 @@ Now in unstable. <braunr> ok that mmap fix looks fine, i'll add comments and commit it soon +## IRC, freenode, #hurd, 2014-03-03 + + <youpi> braunr: did you test whether + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + does indeed fix locale generation? + <braunr> youpi: it doesn't, which is why i applied + http://git.sceen.net/hurd/glibc.git/commitdiff/da2d6e677ade278bf34afaa35c6ed4ff2489e7d8?hp=9a079e270a9bec7e1fe28aeda63e07c1bb808d44 + + # IRC, OFTC, #debian-hurd, 2013-06-20 <youpi> damn diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index d5c0272c..a66202c8 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -561,6 +561,23 @@ Tom Van Cutsem, 2009. <teythoon> ^^ +### IRC, freenode, #hurd, 2014-03-02 + + <youpi> braunr: what is the status of the thread storm issue? do you have + pending code changes for this? + <youpi> I was wondering whether to make ext2fs use adaptative locks, + i.e. spin a bit and then block + <youpi> I don't remember whether anybody already did something like that + <braunr> youpi: no i don't + <braunr> youpi: i attempted switch from spin locks to mutexes once but it + doesn't solve the problem + <braunr> switching* + <gg0> found another storm maker: + <gg0> $ dpkg-reconfigure gnome-accessibility-themes + <gg0> aka update-icon-caches /usr/share/icons/HighContrast + <youpi> braunr: ok + + ## Alternative approaches: * <http://www.concurrencykit.org/> diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn index da7bdc7d..fc9c2f18 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -108,3 +108,853 @@ See also [[nightly_builds]]. <pere> I would like to see something like <URL: http://jenkins.debian.net/view/g-i-installation/job/g-i-installation_debian_sid_daily_lxde/lastBuild/ > for hurd. + + +## IRC, OFTC, #debian-hurd, 2014-02-26 + + * gg0 setting up jenkins, almost time to give up + <pere> gg0: why do you set up jenkins? + <gg0> because i want to fail at doing all things, not just something ;) + <gg0> oops seems my setup just sent emails to jenkins+debian-qa + holger@layer-acht.org :/ + <pere> #debian-qa will understand. :) + + +## IRC, OFTC, #debian-hurd, 2014-02-27 + + <gg0> almost managed to multiboot + <gg0> it gets stuck at "start ext2fs.static" + <gg0> any idea? + <teythoon_> multiboot what ? + <pere> gg0: that sound like the race blocking boot some times. + <teythoon_> no + <teythoon_> that'd print more + <gg0> teythoon: booting hurd with qemu without grub + <teythoon> oh cool + <teythoon> can you paste your qemu arguments somewhere ? + <azeem> probably ext2fs.static got passed a wrong commandline? + <gg0> they are the grub ones but gnumach needs to be uncompressed + <gg0> otherwise qemu complains saying linux kernel is too old + <teythoon> yes, i got past that one + <teythoon> but my qemu keeps crashing + <teythoon> can you please paste the command you used ? + <gg0> "qemu: linux kernel too old to load a ram disk" + <gg0> well, my fun level would really decrease :) + <azeem> if you pasted the commands you used? + <youpi> gg0: if it talks about "linux", it's not actually using multiboot + <gg0> azeem: yep :) + <gg0> youpi: i think it just can't distinguish, btw bt uncompressing it, it + boots + <youpi> gg0: well, "any idea?" means you are requesting help + <youpi> but without pasting the line, we can't divine what can be going + wrong + <youpi> gg0: well, if it can't see that gnumach *can* handle multiboot + modules, qemu is very broken + <gg0> modules are all loaded, multiboot options seems working well + <gg0> ie. -initrd "file1 arg=foo,file2" + <azeem> arg=foo? + <teythoon> fwiw, i tried http://paste.debian.net/84408/ + kvm -m 256 \ + -kernel gnumach \ + -append 'gnumach root=device:hd0s1' \ + -initrd "0.master/hurd/ext2fs.static ext2fs \ + --multiboot-command-line='\${kernel-command-line}' \ + --host-priv-port='\${host-port}' \ + --device-master-port='\${device-port}' \ + --exec-server-task='\${exec-task}' -T typed device:hd0s1 \ + '\$(task-create)' '\$(task-resume)',\ + 0.master/lib/ld.so.1 exec /hurd/exec '\$(exec-task=task-create)'" \ + -drive 'file=/media/pool/hurd-tests/image.qcow2,cache=writeback' -snapshot + <gg0> http://postimg.org/image/esywbywh9/ + <gg0> azeem: pasted from man qemu + <gg0> here screenshot ^ + <teythoon> is this the stock debian ext2fs.static ? + <azeem> gg0: are the ext2fs.static arguments cutoff at + "-exec-server-[...]"? + <gg0> teythoon: yes, everything from last CD image + <teythoon> which you copied to the host ? + <gg0> azeem: as you can see just below --exec-server-task=3 + <gg0> teythoon: loop mounted, like jenkins does + <teythoon> ok + <teythoon> the early hurd bootstrap code is very delicate + <teythoon> and often, the bootstrap just hangs with no indication why + <teythoon> we won't even notice the rootfs or the exec server crashing for + example + <gg0> replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths with yours: + <gg0> --kernel gnumach --initrd "initrd.gz initrd + \$(ramdisk-create),ext2fs.static ext2fs + --multiboot-command-line=\${kernel-command-line} + --host-priv-port=\${host-port} --device-master-port=\${device-port} + --exec-server-task=\${exec-task} -T typed gunzip:device:rd0 + \$(task-create) \$(task-resume),ld.so.1 exec /hurd/exec + \$(exec-task=task-create)" + <teythoon> you are missing the kernel command line, no? + <gg0> teythoon: afaiu it takes it at runtime from itself if any + <gg0> if anyone passes --append + <gg0> in pasted screenshot i pass desktop=lxde + <gg0> need to pass something like gunzip:device:rd0? on cd image it doesn't + pass anything + <youpi> no, it's already passed to ext2fs in the multiboot command line + <gg0> ok + <gg0> -T typed + <teythoon> i do not see any significant difference between your arguments + and mine + <teythoon> for me, kvm/qemu still crashes + <teythoon> % kvm --version + <teythoon> QEMU emulator version 1.1.2 (qemu-kvm-1.1.2+dfsg-6, Debian), + Copyright (c) 2003-2008 Fabrice Bellard + <gg0> teythoon: i don't have any "'" :) and too many gnumach, one in append + too + <teythoon> yes + <teythoon> but that shouldn't cause kvm to crash + <gg0> oh + <gg0> here QEMU emulator version 1.7.0 (Debian 1.7.0+dfsg-3) + <gg0> jessie on amd64 + <gg0> seems quite older + <teythoon> indeed + <gg0> wheezy vs current jessie + <teythoon> yes + <gg0> teythoon: qemu 1.7.0 is on wheezy-backports + <gg0> anyone tried to reproduce it? + + +## IRC, freenode, #hurd, 2014-02-27 + + <gg0> options to boot hurd with qemu multiboot: + <gg0> 17:54 < gg0> replace gnumach, initrd.gz, ext2fs.static, ld.so.1 paths + with yours: + <gg0> 17:54 < gg0> --kernel gnumach --initrd "initrd.gz initrd + \$(ramdisk-create),ext2fs.static ext2fs + --multiboot-command-line=\${kernel-command-line} + --host-priv-port=\${host-port} --device-master-port=\${device-port} + --exec-server-task=\${exec-task} -T typed gunzip:device:rd0 + \$(task-create) \$(task-resume),ld.so.1 exec /hurd/exec + \$(exec-task=task-create)" + <gg0> gnumach needs to be uncompressed + <gg0> this gets stuck at "start ext2fs.static:" + <teythoon> indeed, same for me + <braunr> i strongly suspect qemu multiboot support to be incomplete + <braunr> i couldn't make it work well enough with x15 either + <gg0> if gnumach is compressed, "qemu: linux kernel too old to load a ram + disk" + <braunr> i think that's a grub specific feature + + +## IRC, freenode, #hurd, 2014-02-28 + + <gg0> start ext2fs.static2: ext2fs: device:rd0: panic: get_hypermetadata: + bad magic number 0xd7f0 (should be 0xef53) + <gg0> \o/ it boots + <teythoon> gg0: what was wrong ? + <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz + \$(ramdisk-create),/path/to/ext2fs.static + --multiboot-command-line=\${kernel-command-line} + --host-priv-port=\${host-port} --device-master-port=\${device-port} + --exec-server-task=\${exec-task} -T typed gunzip:device:rd0 + \$(task-create) \$(task-resume),/path/to/ld.so.1 /hurd/exec + \$(exec-task=task-create)" + <teythoon> gg0: uh, using absolute paths fixes this ? + <gg0> teythoon: not necessary, just to be clearer + <gg0> solved by removing initrd between initrd.gz and ramdisk-create, and + ext2fs between ext2fs.static and multiboot-command-line + <gg0> also exec between ld.so.1 and /hurd/exec + <teythoon> gg0: oh, i see + + +## IRC, OFTC, #debian-hurd, 2014-02-28 + + <gg0> --kernel /path/to/uncompressed-gnumach --initrd "/path/to/initrd.gz + \$(ramdisk-create),/path/to/ext2fs.static + --multiboot-command-line=\${kernel-command-line} + --host-priv-port=\${host-port} --device-master-port=\${device-port} + --exec-server-task=\${exec-task} -T typed gunzip:device:rd0 + \$(task-create) \$(task-resume),/path/to/ld.so.1 /hurd/exec + \$(exec-task=task-create)" + <gg0> multiboot works + <pere> cool. + <pere> gg0: are you able to feed the installer one of the preseed files at + <URL: http://jenkins.debian.net/d-i-preseed-cfgs/ >? + <gg0> though jenking translates double quotes, need to escape the world + <pere> debian_sid_daily_lxde_preseed.cfg seem like a good candiate. :) + <gg0> pere: i'm working on that, stuck at working around that mandatory + double quote + <gg0> *initrd double quote + <youpi> gg0: could you paste your command line on the hurd wiki? + <gg0> ok got a g-i-installation_debian_sid_daily_hurd_lxde able to boot + <gg0> let's provide a preseed + <gg0> shouldn't there be some info/debug consoles from tty 2 to 4? + <youpi> there should be + <gg0> maybe i can't send alt+NUM from vlc + <youpi> ah, yes + <youpi> you need to use the menu for that + <youpi> press f8 + <gg0> great + <gg0> (found out C+A+{1,2,3} give interesting monitor,serial,parallel + consoles btw) + <gg0> not much options on menu + <gg0> just clipboard management, quit, full screen, send ctrl-alt-del, send + F8 + * gg0 takes "great" back + <gg0> i guess it depends on vnc implementation + <gg0> don't ask me how i found out one can switch console with + ... left/right arrow keys + <youpi> without alt pressed? + <gg0> without alt pressed + <youpi> I've already seen that with qemu, when focusing into/out from the + qemu window by using alt + <youpi> somehow the alt state gets stuck + <gg0> so you mean if i close viewer then reattach it, it doesn't happen + anymore? let's see + <gg0> you're right + <gg0> though yes alt+left/right switches consoles + <youpi> the last is expected :) + <gg0> it says kbd-udeb doesn't exist so it falls back to + hurd-debian-ports-udeb + <youpi> that's not a problem + <gg0> no partman-auto? + <youpi> it should be working + <gg0> i meant if it was installed but yes it gets it along with others + + +## IRC, OFTC, #debian-hurd, 2014-03-01 + + <gg0> partman-auto would need to be patched to be able to discover + available disks + <gg0> worked around by forcing /dev/hd1, jenkins creates disk with index=1 + <gg0> stuck at installation-report installed. seems it can't manage to + umount(then remount) /cdrom gracefully + <gg0> or better it gets stuck at apt-cdrom ident + <gg0> something like https://bugs.debian.org/598457 + + +## IRC, OFTC, #debian-hurd, 2014-03-02 + + <gg0> teythoon: curiosity, correct qemu multiboot options still make old + qemu crashing? + <teythoon> gg0: no idea, i'll try it later + + <gg0> youpi: any chance to have monthly/weekly (daily would be too much i + guess) isos/images? can i help somehow? + <youpi> I am wondering why having that + <youpi> since we have up-to-date mirrors + <gg0> i'd say to install with latest installer/gnumach/hurd/eglibc + <youpi> so that means also rebuilding the d-i image + <gg0> and in general to not have to manually produce them + <pere> youpi: the point is to automatically test the current images using + jenkins.debian.net, I believe. for that to work, current images need to + exist. :) + <gg0> not only. i think saving youpi's time is also important + <youpi> gg0: it doesn't really take me much time to generate images + <youpi> it's about a few command lines to start, and then work on something + else :) + <gg0> well though it still requires manual intervention which is not + scheduled and also error prone btw + <youpi> gg0: I guess the most important help you could provide would be to + actually track when the autobuild breaks :) + <gg0> what pros keeping it manual? i don't think disk space saving + <youpi> it's not really a question of manual, but the frequency + <youpi> I prefer to test manually before uploading something on my + somehow-official directory on people, anyway + <youpi> but that doesn't mean we can't have weekly builds somewhere else + indeed + <youpi> it's just that for tests it's good to have several images backlog, + but then it takes disk + <gg0> well we could keeping "official" ones + say 6 monthly and say 4 + weekly + * gg0 randomizes retention + <gg0> -ing + <teythoon> gg0: check out my hurdtest program + <teythoon> it updates qemu images automatically, and runs a test suite, + creates snapshots + <gg0> youpi: you'd just take actually care of official ones + <teythoon> and it can zero-fill the disk images to compact them for + publication + <youpi> gg0: and have a cron for the others + <youpi> on mirror.ftp-master + <gg0> nice, we already have a disk image generator then + <teythoon> i shall clean it up and merge stuff that i have changed locally + <teythoon> i covered it in my early blog posts + <teythoon> i use it extensively to test the packages from hurd-ci + <gg0> great. so usually at this point /me can't do anything so good work! + lol + <youpi> crontabs are in place, scheduled on monday mornings + <youpi> I have already completed a run, can be seen in weekly-0 + <gg0> great! + <gg0> assuming it will work forever without maintenance, how many minutes + you'll save per month? :) + <youpi> I don't think that'll save me time per month + <youpi> since it's just an additional thing + <gg0> youpi: so weekly-0 will always be the latest weekly (same about + monthly) ? + <youpi> yes + <gg0> how about adding -YYYYMMDD after -1 CD/DVD/NETINST number? + <youpi> that'd mean more scripting + <gg0> just to distinguish them + <youpi> we already have timestamps from the server + <gg0> unfortunately i can't script myself, i can suggest though :) + <gg0> or scripts are available somewhere? + <gg0> so current/ should be a link to weekly-0? + <youpi> on mirror.ftp-master.debian.org, but I guess you don't have access + to it + <youpi> no + <youpi> definitely no + <youpi> the point of current/ is to have something tested + <gg0> ok + <youpi> while weekly/monthly are most probably to get broken + <youpi> so let's not point people at that + <gg0> same story about diskimage? how do you generate them? + <gg0> how about teythoon's way? + <youpi> I do it by hand at the moment, but scripts would be welcome indeed + <youpi> http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.txt + <gg0> ok now stuck at grub install + + +## IRC, OFTC, #debian-hurd, 2014-03-03 + + <gg0> i probably should force /dev/hd0 as i did for /dev/hd0s1 as root + device + <gg0> if it's possible + <youpi> what do you mean by forcing /dev/hd0s1 as root device ? + <youpi> you shouldn't have to do that + <youpi> my fear is that these additional images will mostly just bring + additionnal reports + <gg0> i had to specify it in preseed + <youpi> which won't really decrease the amount of work + <gg0> as partman-auto/disk + <gg0> it can recognize available disks + <gg0> that's also because it can't list root partitions on rescue mode + <youpi> well, all I can say without having (again) to spend time on it, is + that you're not supposed to have to do that + <youpi> why are you using rescue mode? + <youpi> if it can't list root partitions, then of course partman can't work + <gg0> well, rescue mode should work + <youpi> if you delve into non-tested parts of d-i, you'll surely encounter + bugs + <youpi> well, less "should" than plain "d-i" + <youpi> in that I've never really tested it + <youpi> so don't be surprised that some bugs remain + <gg0> no problem + <youpi> but again, we don't really need more bug reports + <youpi> but rather bug fixing + <youpi> we already have enough to fix, no need to delve into advanced + things + <gg0> sure, i'm just trying to make it work with all its limitations + <gg0> it autopartition the disk well, it can't just make one choose among + disks because it can't probe and list them + <youpi> then fix the probe & list + <gg0> i'd like doing it, i'm better at working around for now though :) + <gg0> one blocker is mount/umount stuff + +[[glibc#mount]]. + + <youpi> well, you'll have to get into fixing bugs for real someday + <youpi> otherwise this is just adding to TODO lists + <youpi> what mount/umount stuff? + <gg0> (took a quick look at partconf) + <gg0> non-existent mount.h for instance + <gg0> do we have replacements? + <youpi> not that I know of + <gg0> 21:53 < teythoon> gnu_srs1: i put a small hacks entry in the list + about moving the mount/umount functionality from our utilities to the + libc + <youpi> ok + <gg0> another thing i'd really like to see would be a physical shutdown, + halt-hurd which actually poweroffs the system + <gg0> how to switch to sysvinit by default? next sysvinit upload? + <youpi> physical shutdown means implementing APM or ACPI + <gg0> have to teach jenkins it can shut it down :/ + <youpi> I'm extremely far from having the will for this + <youpi> switching to sysvinit by default is a matter of saying that we want + to do it + <youpi> I already asked for this on the list without answer IIRC + <gg0> i can't find anything + <youpi> anyway, just propose on the list + <gg0> d-i grub-installer/bootdev string /dev/hd0 - here it is + <gg0> next run should not need any interaction, though it needs 20 mins to + understand it has to destroy it and run won't be successful :/ + <gg0> due to missing acpi/apm + <gg0> first graphical automated install http://postimg.org/image/vgagj06q7/ + <gg0> it seems 720x400 + <gg0> though jenkins passes video=vesa:ywrap,mtrr vga=788 + <gg0> by reconnecting it switched to 800x600 + http://postimg.org/image/h32qjykrx/ + <gg0> but seems stuck now and i can't even switch from graphical to + consoles + <gg0> unusually stuck at scanning cdrom + <gg0> i'll check text install to see if it gets stuck there too + <gg0> text install switches from 720x400 to 640x400 + <gg0> i confirm it gets stuck on scanning cdrom, i guess because of this + one https://bugs.debian.org/728153 which already broke load-install-cd i + already had to workaround + <pere> gg0: are you in contact with h01ger to update jenkins.debian.net + with your cool installation code? + <gg0> pere: still trying to have something working + <gg0> plus with new weekly cd, apt-cdrom bug makes install getting stuck at + first Scanning cdrom: + <gg0> 03:44 < gg0> i confirm it gets stuck on scanning cdrom, i guess + because of this one https://bugs.debian.org/728153 which already broke + load-install-cd i already had to workaround + <youpi> do we really need the CD-1 image in weekly builds? + <gg0> just netinst? + <youpi> yes + <gg0> well, i don't know debian installer well. what's the difference + between CD and NETINST besides that CD has more packages user doesn't + need to download? + <gg0> has CD anything not in NETINST which is worth to continously test? + (talking about jenkins) + <youpi> that's only it, yes + <gg0> btw new ACPI on hurd consists of serial console to file + looping + grep "In tight loop: hit ctl-alt-del to reboot" && kill qemu + <gg0> anything better? + <gg0> filed http://bugs.debian.org/740673 + <gg0> without a patch just to express my great laziness :p + <youpi> well, I'm afraid nobody in the debian-boot team will attempt + anything at this + <youpi> is it reproducible on linux? + <gg0> nope + <gg0> my guess is that's due to udev, need a deeper check btw + <gg0> i mean non-udev cases like hurd maybe are not handled well + <youpi> maybe try on kfreebsd then? + <gg0> just guessing + * gg0 trying on kfreebsd + + +## IRC, OFTC, #debian-hurd, 2014-03-04 + + <gg0> hurd install started getting stuck running os-prober, final grub + install phase + <gg0> youpi: yes i confirm it affects kfreebsd too + <youpi> then please say so in the bug + <youpi> otherwise most probably but me in the debian-boot team will care + <youpi> +nobody + <gg0> that might get more attention from d-boot team? + <gg0> ok + <youpi> also Cc debian-bsd@ + <youpi> they will care + <youpi> and tell about the hint as being the non-udev case + <youpi> too much information or ideas is never a bad thing :) + <gg0> done + <gg0> (now i know notfound does remove found versions instead of adding + notfound versions) + <gg0> crazy things. to unblock os-prober i had to settrans -fg + /target/media/./cdrom0 + <gg0> it was mounting /dev/hd0s1 ... + <gg0> i suspect apt-cdrom is to blame again + <gg0> ok now jenkins just managed to start the installed system + <gg0> and it's configured to make vncdo testing it + <gg0> i'd need a graphical-working cd with old-apt to continue + <gg0> let's try to install old apt on weekly-0 + <gg0> "cdrom drive contains a cd which cannot be used for installation" + <gg0> i think a sort of non-authenticated anymore + <gg0> ehm.. http://paste.debian.net/plain/85224/ + <pere> gg0: nice. :) + <gg0> with apt 0.9.15.1 which should be good + <gg0> pere: it did mount /dev/hd0s1 under /media/cdrom0 + <gg0> 0.9.15.5, correctly i think, asks to insert it cdrom. but finally + both mount /dev/hd0s1 instead of /dev/hd2 + <gg0> -it + <gg0> cause they both can't detect where cdrom is i guess + + +## IRC, freenode, #hurd, 2014-03-04 + + <gg0> we could talk about apt-cdrom https://bugs.debian.org/740673 + <gg0> how should system recognize cdrom device? + <gg0> there's no /dev/cdrom link to actual cdrom device + <gg0> /dev/cd[01] are scsi devices if i'm not wrong + + +## IRC, OFTC, #debian-hurd, 2014-03-05 + + <gg0> installer gets stuck running os-prober, seems because + /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it + gets stuck reading it + +[[hurd/translator/mtab/discussion#chroot]]. + + <gg0> youpi: could you publish script to rebuild CDs you scheduled? with + last official CD (20140212) mtab on /target dies and that seems getting + os-prober stuck. last (and only) weekly has recent apt-cdrom so it gets + stuck wrongly asking to change cdrom + <youpi> see the readme file + <youpi> err, you say it's the 0212 build which fails? + <youpi> I had tested that before uploading + <youpi> so the issue comes form the installed packages, not from the CD + udebs + <youpi> did you test with no network mirror? + <gg0> no i didn't. should it find all packages it needs from cd? + <youpi> sure, that's what netinst and dvd-1 are, as opposed to netboot + <gg0> lxde desktop probably not + <youpi> indeed + <youpi> though with the dvd in principle it should + <youpi> (if all deps were avaijlable at image build time) + <youpi> gg0: btw if you haven't noticed, there's a daily too + <gg0> youpi: till apt-cdrom is not fixed, they all will be broken, stuck at + "Scanning cdrom" + <youpi> gg0: did you try to bisect which git change produces the apt-cdrom + bug? + <gg0> youpi: all in bug in question + <gg0> youpi: https://bugs.debian.org/740673 + <youpi> is there the precise git commit id in the bug log? + <gg0> + http://anonscm.debian.org/gitweb/?p=apt/apt.git;a=commitdiff;h=62dcbf84c4aee8cb01e40c594d4c7f3a23b64836 + <youpi> well, don't tell that to just me, but the bug report... + <gg0> bug report says "See <bug>" where bug is + https://bugs.debian.org/728153 + <youpi> gg0: bug report doesn't say it was *tested* that it is that changes + which broke things + <gg0> i don't think we could get it reverted just because it breaks hurd + (+kfreebsd to check) debian installer + <youpi> of course, but that's at least where developers can have a look at + <gg0> well ok i could have been more clear + <youpi> it's *WAY* better than having no idea where to have a look at + <youpi> gg0: btw, that's why the README file advises not to use a network + mirror, to avoid such kind of issues + <youpi> you can't expect sid not to be not-broken :) + <gg0> one gets Resource lost even when install is just started, no packages + from any mirror + <gg0> https://bugs.debian.org/740673#19 + + * gg0 installing without mirrors, without desktop, without lxde + <gg0> same problem + <gg0> so problem has nothing to do with installing from mirrors + <youpi> what's odd is that I don't get this issue at all with the 20140212 + upload at least + <youpi> kvm -cdrom debian-7.0-hurd-i386-NETINST-1.iso -drive + file=blip,cache=unsafe -m 1G + <youpi> no more, no less + <gg0> it must depend on preseed and/or kernel append options + <youpi> possibly + <gg0> oh wait here qemu multiboot + <youpi> that shouldn't have any impact + <youpi> did you leave the command line somewhere on the wiki so I can try + with it, just to be sure? + <gg0> + http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot + <gg0> 5€ on qemu multiboot as the culprit + <gg0> you should also see it sometimes double-mounts /dev/hd0s1 under + /target and /target/./media/cdrom(!) + <gg0> but that's due to new apt it in-targets (= installs under /target) + <youpi> gg0: rather use the gnumach, ld.so and ext2fs.static from the ISO + image you are booting + <youpi> especially for ld.so, which has to be the same as the libc + installed in the initrd + <youpi> ah, you're getting the initrd there too + <youpi> well, really use the same as the ISO + <gg0> i already do + <youpi> ah, ok, so the wiki example is just with current + <youpi> but the wiki example doesn't use -cdrom to provide the ISO ? + <gg0> no it doesn't even mention you could also use a cdrom + <gg0> it just shows how to use qemu multiboot options + <youpi> it seems one have to avoid any blanks in the multiboot option + <youpi> notably before file names + <gg0> well, actually it works but it's rather incomplete + <youpi> well, it shows how to boot the installer + <youpi> not how to boot an installed system + <gg0> removed spaces, added <other_qemu_options> option + <gg0> here qemu binary is qemu-system-x86_64 instead of qemu-kvm and it + crashes without --enable-kvm + <gg0> qemu: fatal: Trying to execute code outside RAM or ROM at + 0x000000010010001e + <youpi> rather use qemu-system-i386 + <gg0> i was just complaining i wrote qemu-kvm on wiki but i did never + actually run that command as is + <gg0> ouch right, -i386 doesn't require enable-kvm + <gg0> (i'll never know why) + <youpi> -x86_64 is buggued + <youpi> 0x000000010010001e should have been truncated to 0x0010001e since + it's 32bit mode + <gg0> i see + <gg0> any luck reproducing mtab issue? + <youpi> still not + +[[hurd/translator/mtab/discussion#chroot]]. + + +## IRC, OFTC, #debian-hurd, 2014-03-06 + + <youpi> http://paste.debian.net/85535/ + <youpi> no issue + <youpi> (no network mirror) + <gg0> full install till grub-installer? + <youpi> yes + <youpi> and reboot + <gg0> -append 'auto=true mirror/suite=sid console=com0 priority=critical + locale=en_US keymap=us + url=http://10.0.2.1//d-i-preseed-cfgs/debian_sid_daily_hurd_lxde_preseed.cfg + video=vesa:ywrap,mtrr vga=788 -- quiet' + <gg0> i should provide preseed too + <youpi> well, of course + <youpi> always provide as much information as possible + <youpi> so there's also your preseed file + <gg0> not much different from + http://jenkins.debian.net/d-i-preseed-cfgs/debian_sid_daily_lxde_preseed.cfg + <gg0> but you need to force a couple of things + ugly workaround for broken + apt-cdrom ident + <youpi> well, I didn't even know that jenkins had that pressed file + <youpi> well, here apt-cdrom is not needed + <youpi> +hacks + <youpi> since that's the old image we're checking + <gg0> well ok, given you take everything from cd only, yes + <gg0> here no mirror, no desktop, no lxde + http://paste.debian.net/plain/85538/ + <gg0> i'm trying this one too + <gg0> main difference seems to be i usually use CD-1, not NETINST + <gg0> had to add -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + <gg0> here target mtab is already crashed + <gg0> because some package already tried to read /target/proc/mounts + <gg0> youpi: reproduced there? + <gg0> .o(well, maybe he's been sleeping for ~50 mins) + <youpi> nope, I'm working on upgrading servers + <youpi> I'm sorry, but your testcase is not really easy to reproduce :) + <gg0> do you have apache on your host? just put preseed in the root, vm + will take it + <gg0> full command line is what you pasted + -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + <gg0> what else? when it starts debstrapping, open a console and check + procfs and mtab processes + <gg0> err, what you paster + -append i pasted + -net nic,vlan=0 -net + user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 + <gg0> *pasted + <gg0> which is http://paste.debian.net/plain/85554/ + <gg0> surely keyboard layout doesn't help, here at least + * gg0 tries to reproduce without preseed + <gg0> i can't reproduce it + <gg0> it doesn't crash + * gg0 enabling all options but preseed + <gg0> need to wait 31% of Installing base system to have the second procfs + <gg0> ok got Resource lost even without preseed + <gg0> youpi: you can reproduce it by adding -append console=com0 to what + you pasted. that breaks grub-installer, it gets stuck at 66%, while runs + os-prober + <youpi> ah + <gg0> how can that affect /target/proc/mounts? + <youpi> no idea + <gg0> couldn't daily be here? http://d-i.debian.org/daily-images/ + <youpi> if I knew how to push files there, sure + <gg0> asking on #debian-boot would be a starting point i guess + <youpi> probably + <gg0> me asking on behalf of youpi would not a good one i think, given + whatever will the answer i can't do anything + <gg0> +be + <youpi> you can still trasmit me + <youpi> never understimate the little time you can save other people by + doing some bits of work + <gg0> well, i would not even have to repaste lines here given you joined + there too + <gg0> never understimate what "help with laziness" means :) + <youpi> not necessarily repasting, but at least highlighting me + <youpi> so I know where to read in the #d-b logs + <gg0> there are no isos there, i'm missing something + <youpi> there are no daily isos + <youpi> only weekly isos + <gg0> so seems i have to reask initial question with this url + http://cdimage.debian.org/cdimage/weekly-builds/ + <gg0> oh wait they are from testing, that's why no hurd ones + <gg0> i guess they could be here though + http://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/ + * gg0 asking on #debian-cd + * gg0 would ignore non-DD gg0 asking whatever + <youpi> people don't really ask themselves who is a DD and who is not + <youpi> as long as you provide information in your question, it'll get + answered + <gg0> teythoon: interested in reproducing mtab-dying-under-chroot? + <gg0> oh just realized it's not only under a chroot, chroot is on another + disk. might that make the difference? + <gg0> i didn't try to reproduce it by creating a chroot on a different + disk, which is what installer does + * gg0 wonders if it would have been better filing a bug against + cdimage.debian.org + <gg0> if no one fixes console=com0 thing, i have to think about a new acpi + <gg0> ok managed to workaround apt bug in installer, i can graphically + install last weekly + <gg0> no console=com0 means no vm shutdown though + <pere> gg0: wow. impressed! + <gg0> patching CI to make CI workaround bugs CI spots is not so good + <gg0> any idea about another shutdown trick without console=com0 till + teythoon or youpi fix it? + <pere> nope + <gg0> current one: vm writes serial console to file and host loops grepping + "In tight loop: hit ctl-alt-del to reboot" + <gg0> -watchdog might be an alternative + <gg0> if there are watchdog agents that can run on hurd + <gg0> "watchdog" for instance doesn't build on hurd + <pere> it need kernel support + * gg0 testing -add-fd + + +## IRC, freenode, #hurd, 2014-03-07 + + <gg0> teythoon: just mounted an additional fs, it's mounted but not present + in proc/mounts + <braunr> gg0: how did you mount it ? + <gg0> i was under /root, sid-chroot is the mountpoint. i did mount /dev/hd3 + sid-chroot (relative path) + <braunr> does fsysopts confirm a new translator is running on sid-chroot ? + <gg0> i shut down vm, working on another one by mounting the same disk + which hosts a debchroot + <gg0> i'm trying to reproduce the mtab-dying-on-chroot issue i get with + debian installer + <gg0> at the end, os-prober gets stuck by reading /target/proc/mounts + (target is the installed system) + <gg0> to be precise it gets stuck at second access. at first it gives + Resource lost + <gg0> didn't manage to reproduce so far + <gg0> environment is pretty the same: booting with qemu multiboot + http://darnassus.sceen.net/~hurd-web/hurd/running/qemu/#QEMU_Multiboot + <gg0> so root on initrd + chroot on real disk + <gg0> what's weird is that issue vanishes by removing console=com0 from + -append options + + +### IRC, freenode, #hurd, 2014-03-08 + + <gg0> os-prober doesn't get stuck anymore and grub can install + <gg0> my guess is that without console=com0 /target/proc/mounts is just + accessed once + + +## IRC, OFTC, #debian-hurd, 2014-03-08 + + <gg0> youpi: from #debian-cd http://paste.debian.net/plainh/559f669b + <gg0> any quick way to recreate initrd? + <teythoon> gg0: i'm working on that + <gg0> teythoon: that what? + <teythoon> gg0: there is genext2fs, i have some patches that allows one to + create nodes with passive translator records + <gg0> recreating initrd? + <teythoon> yes + <teythoon> in the meantime, you can mount the existing initrd and modify it + <gg0> well i'm following this one to rebuild whole cd then take an updated + initrd to test with your repo + <gg0> http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i + <gg0> probably too much work to get that + <gg0> copying current /hurd to new initrd would be enough? + <youpi> just copy the precise translator you need + <youpi> also, no need to rebuild the whole cd just to replace the initrd + <youpi> simply copy the content of an existing is + <youpi> iso + <youpi> replace the initrd.gz there + <youpi> and then use grub-mkrescue to rebuild the ios + <youpi> development would be horrible if you had to rebuild everything from + zero everytime + <youpi> first thing to do when developping is first take the time to find + ways to work efficiently + <gg0> i'd want to try multiboot with teythoon's gnumach/hurd but boot gets + stuck with old initrd + <youpi> unfortunately I had to apply some patches + <youpi> first in d-i because isc-dhcp doens't work -> use the debian-ports + version + <gg0> so i could simply copying whole /hurd dir to new initrd + <gg0> -ing + <youpi> then in d-i to automatically enable the debian-ports mirror + <youpi> and last in the debian-cd to include debian-ports-archive-keyring + <youpi> you'd also need to copy the libs + <gg0> anything missing here? + http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i + <gg0> libc0.3 on initrd is still 2.17 + <gg0> mini.iso doesn't like any mirror + <gg0> "mirror does not support the specified release" + <gg0> something wrong/missing in my rebuilt + <gg0> youpi: anything wrong in http://paste.debian.net/plain/86258 ? + <gg0> i have/had problems with name resolution + <youpi> gg0: the patch makes sense for -bsd too, Cc them too + <gg0> i was wondering how many hunks in your patches are upstreamable + <youpi> normally it's zero + <gg0> + http://people.debian.org/~sthibault/hurd-i386/installer/patch-debootstrap + <gg0> why "release" instead on "main" by default? sid is never released + <youpi> only because my mirror directory is hacked one + <youpi> that merges debian.org, debian-ports.org, and my repo + <youpi> and I don't rebuild Release files, just Packages files + <gg0> i keep getting gpgv: BAD signature from "Debian Archive Automatic + Signing Key (7.0/Wheezy) <ftpmaster@debian.org> + <gg0> just before creating debootstrap chroot + <gg0> i applied hunk #2 only, installed modified debootstrap and put debs + under localdebs/ + <gg0> trying a different mirror + <youpi> I don't know what issue you are encountering + <youpi> but again, it's way simpler and faster to just patch existing + images, rather than rebuilding them from zero + <gg0> ok just read i'd need a local mirror to build isos + <gg0> better using netinst and proxy cache + + +## IRC, freenode, #hurd, 2014-03-09 + + <gg0> http://postimg.org/image/oca8ormaj/ + <gg0> with teythoon's repo too ^ + + +## IRC, OFTC, #debian-hurd, 2014-03-09 + + <gg0> ok i'm out of tests, i get Resource lost with teythoon's gnumach/hurd + packages in initrd too + <gg0> http://postimg.org/image/oca8ormaj/ + <gg0> thread storms, dead locks, resource lost + <gg0> i find assonance + + +## IRC, freenode, #hurd, 2014-03-09 + + <teythoon> gg0: strange + <gg0> teythoon: shouldn't there be a patch which shows pid instead of task? + <gg0> 20:43 < teythoon> task /hurd/procfs(19) <EF><BF><BD>O<EF><BF><BD> + deallocating an invalid port 1049744, most probably a bug. + <teythoon> there is + <teythoon> i placed the functionality in proc first, but the wiki suggested + to put it in the exec server instead + <teythoon> i did that, it has the advantage, that the argv vector is easily + accessible + <teythoon> so i can also include the program name + <teythoon> but there are two programs, that are not started using the exec + server + <teythoon> the root filesystem and the exec server itself + <teythoon> so for these two processes, the approach does not work + <gg0> i see. so here we got two which could come from + ext2fs.static(initrd), exec(initrd) and ext2fs(chroot) + http://postimg.org/image/e3qyafd0b/ right? + <gg0> i also noticed that once mtab dies, by killing its procfs parent, + they both restart, but /target/proc is not in /proc/mounts anymore + <youpi> teythoon: for those we could use the first word of the module + command line + <gg0> restart doesn't means that by accessing /target/proc/mounts again it + works btw, it'll give Resource lost again + <teythoon> youpi: indeed + <teythoon> gg0: no, the ext2fs for /target will be started by the exec + server + <gg0> ok two invalid ports one from ext2fs.static and one exec then + <teythoon> gg0: what makes you attribute one to the exec server ? + <teythoon> i'm pretty sure that there is a bug in libfshelp, it's easily + triggered by killing an translator like procfs + <teythoon> i must have introduced it with the translator list work i've + done for the mtab translator + <gg0> teythoon: a totally wrong task-is-a-process reasoning probably + <gg0> just mounted another procfs which seems to work + <gg0> http://postimg.org/image/q6w9xzo2j/ + http://postimg.org/image/cr998jfkr/ + <teythoon> gg0: the mtab translators in your screenshots are oldish, what's + the point exactly ? + <teythoon> gg0: also, all tasks are processes. task is a mach concept, + whereas process is a posix concept implemented by hurds proc server. it + creates a process object for every mach task. + <gg0> my guess was that given we got two messages with different taskid: + <gg0> 16:01 < gg0> ok two invalid ports one from ext2fs.static and one exec + then + <gg0> screenshot is this one http://postimg.org/image/e3qyafd0b/ + <gg0> btw what do you mean by oldish. except first one 01:18 < gg0> + http://postimg.org/image/oca8ormaj/ the only with current debian + packages, remaining are done with your latest packages + <gg0> in all cases i boot using qemu multiboot + <gg0> root@hurd01:~# cat /proc/version + <gg0> Linux version 2.6.1 (GNU 0.5 GNU-Mach 1.4-486-dbg/Hurd-0.5 + i686-AT386) + <gg0> it wouldn't be bad customizing version somehow, last commit id for + instance + <gg0> or build date + <gg0> user01@jessie01 ~$ cat /proc/version + <gg0> Linux version 3.11-2-686-pae (debian-kernel@lists.debian.org) (gcc + version 4.8.2 (Debian 4.8.2-7) ) #1 SMP Debian 3.11.10-1 (2013-12-04) + <gg0> user01@jessie01 ~$ uname -v + <gg0> #1 SMP Debian 3.11.10-1 (2013-12-04) diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index 3dab6d4c..64b245f2 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -239,3 +239,22 @@ call|/glibc/fork]]'s case. <braunr> teythoon: pahole is a very handy tool :) <teythoon> yes <teythoon> i especially like how general it is + + +# Measurement + +## coulomb + +### [[!message-id "87wqghouoc.fsf@schwinge.name"]] + +## IRC, freenode, #hurd, 2014-02-27 + + <braunr> tschwinge: about your concern with regard to performance + measurements, you could run kvm with hugetlbfs and cpuset + <braunr> on a machine that provides nested page tables, this makes the + virtualization overhead as small as it could be considering the + implementatoin + <braunr> hugetlbs reduces the overhead of page faults, and also implies + locked memory while cpuset isolates the vm from global scheduling + <braunr> hugetlbfs* + <tschwinge> Thanks, will look into that. diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn index 711f7691..59f22187 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -3064,3 +3064,13 @@ License|/fdl]]."]]"""]] mach-defpager) <braunr> rebase it, send it as a patch on bug-hurd, it should be straightforward and short + + +## IRC, freenode, #hurd, 2014-03-04 + + <teythoon> btw, has mcsim worked on vectorized i/o ? there was someting you + wanted to integrate + <teythoon> not sure what + <braunr> clustered pageins + <braunr> but he seems busy + <teythoon> oh, pageins diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn index c3dd4e26..46cc1c1c 100644 --- a/open_issues/ti-rpc_then_nfs.mdwn +++ b/open_issues/ti-rpc_then_nfs.mdwn @@ -103,3 +103,30 @@ re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]]. <pere> failing rpcinfo -p on hurd reported as <URL: http://bugs.debian.org/739674 >. Anyone got a clue how to debug it? + + +## IRC, OFTC, #debian-hurd, 2014-03-03 + + <pere> I was just tipped by sesse that the hurd fix for libtirpc probably + caused RC bug in nfs-common, <URL: https://bugs.debian.org/740491 >. + Have not had time to check it out more closely. + + +## IRC, OFTC, #debian-hurd, 2014-03-04 + + <youpi> pere: I don't really see how debian/patches/05-hurd-port.diff could + break Linux' libtirpc + <youpi> AIUI, the patch has zero effect on non-hurd builds + <youpi> oh wait + <youpi> it's simply missing a reautoconf to get HAVE_SYS_USER_H undefined + in config.h.in + <pere> youpi: I am quite sure I did add the required dh_autoreconf call. + did you see a build log where it was missing? + <youpi> pere: ah, ok. Then 02-rerun-bootstrap.diff can be dropped + <youpi> and I don't have any further idea + <youpi> pere: maybe it's the autoreconf itself which broke something? + <pere> could be. not quite sure how to find out. + <gnu_srs> pere: what about running autoreconf on the previous (working + version)? + <pere> gnu_srs: sound like a good idea. perhaps a good idea to just + disable the two patches as a start. diff --git a/open_issues/versioning.mdwn b/open_issues/versioning.mdwn index 1987b6ca..18fb588e 100644 --- a/open_issues/versioning.mdwn +++ b/open_issues/versioning.mdwn @@ -66,11 +66,8 @@ In context of [[packaging_libpthread]]/[[libpthread]]. could be the perfect moment to fix the /dev/fd/N problem without adding new RPCs, though we'd probably have to break backwards-compatibility in the exec server IIRC... - <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for - reminding! -[[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id -"4BFA500A.7030502@gmail.com"]]. +[[glibc#execve_relative_paths]]. ### `time_t` -- Unix Epoch vs. 2038 diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn index 8901e1c3..88a18a93 100644 --- a/open_issues/virtualization/fakeroot.mdwn +++ b/open_issues/virtualization/fakeroot.mdwn @@ -24,6 +24,8 @@ License|/fdl]]."]]"""]] <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name but apparently not fixed in that case, for some reason +[[glibc#execve_relative_paths]]. + ## IRC, freenode, #hurd, 2013-08-26 @@ -36,6 +38,9 @@ License|/fdl]]."]]"""]] < youpi> yes < youpi> pinotree's exec_file_name is supposed to fix that, but for some reason it doesn't work here + +[[glibc#execve_relative_paths]]. + < pinotree> it was pochu's, not mine < youpi> ah, right < teythoon> ah I see, I was wondering about that @@ -73,6 +78,9 @@ License|/fdl]]."]]"""]] <teythoon> I believe I figured out the argv[0] issue with fakeroot-hurd <teythoon> but I'm not sure how to fix this <teythoon> first of all, Emilios file_exec_file_name patch set works fine + +[[glibc#execve_relative_paths]]. + <teythoon> but not with fakeroot <teythoon> http://git.sceen.net/hurd/hurd.git/blob/HEAD:/exec/hashexec.c#l300 @@ -1293,3 +1301,26 @@ License|/fdl]]."]]"""]] <braunr> teythoon: was it a big package ? <teythoon> half of the hurd package <braunr> that's not a port right overflow then + + +## IRC, freenode, #hurd, 2014-03-05 + + <teythoon> youpi: what about the exec_filename patch series? even though + fakeroot still has some issues (has it?), i consider it worthy for + inclusion + +[[glibc#execve_relative_paths]]. + + <youpi> Roland was disagreeing with it + <youpi> iirc the fakeroot issue was solved + <teythoon> braunr: ^ + <braunr> fakeroot goot a lot more robust than it used to be + <braunr> but i haven't checked that it actually behaves exactly like the + library for corner cases + <braunr> there are minor differences + <braunr> also, it seems to trigger concurrency bugs in ext2fs + <braunr> e.g. git reporting that files either "already exist" or "can't be + found" + <braunr> it happens (rarely) when directly using ext2 + <braunr> and more often through fakeroot + <braunr> i didn't take the time to investigate |