Re: proc leaking
On Sun, Nov 26, 2023 at 08:32:30PM +0100, Samuel Thibault wrote: > I found the issue, it's because of the quiescence support in libports, > which assumes that all threads will sooner or later go through a > quiescent state (because it finished processing a message). But that's > not true, proc doesn't set a thread timeout, and thus some threads can > stay indefinitely stuck in receiving messages. And thus the deferred > dereferencing used by ports_destroy_right never gets achieved. > > I'll push a fix. Very nice catch. -- Richard Braun
Re: glibc transition ongoing
On Mon, Aug 08, 2022 at 09:31:31PM +0200, Samuel Thibault wrote: > There's a glibc transition which is ongoing, whose consequence is > that upgrading libc0.3-dev to 2.34-3 would make some -dev packages > removed. The rebuilds for these packages are ongoing, you just need to > wait for a few days, all you'll be able to upgrade libc0.3-dev to 2.34-3 > without having to remove some -dev packages. Hello, I've upgraded on darnassus.sceen.net and the system cannot boot properly any more. I'm unable to diagnose at this time. -- Richard Braun
Re: Troubles with updating Debian Hurd
On Fri, Oct 08, 2021 at 01:09:38PM +0300, Sergey Bugaev wrote: > On Fri, Oct 8, 2021 at 12:42 AM Samuel Thibault wrote: > > > I've verified that I see the same behavior on darnassus, > > > > I don't see it happen on darnassus. > > Interesting: I've just checked and I no longer see it on darnassus > either! But I'm 100% positive I saw it there. Could it be that > darnassus has been updated in the meantime (between Sep 30 and today)? It most likely has, yes. > (By the way, there seems to be some issue with /home again.) Ugh. I'm not available to fix them right now, but I'll check next week. -- Richard Braun
Re: Hi, I am a newbie to debian-hurd development! I have created a patch for libtorrent-0.13.8
On Tue, Apr 27, 2021 at 09:25:05PM +0900, haha wang wrote:
> Hi, everybody. I am a newbie to debian-hurd
> development and want to contribute to this project. After reading the
> development guide at href="https://www.debian.org/ports/hurd/hurd-devel-debian; rel="noopener
> noreferrer"
> target="_blank">https://www.debian.org/ports/hurd/hurd-devel-debian, I
> decide to fix a broken package found at the recommended page href="https://people.debian.org/~sthibault/out_of_date2.txt; rel="noopener
> noreferrer"
> target="_blank">https://people.debian.org/~sthibault/out_of_date2.txt
> named `libtorrent`. After I download the package
> source and try to build without any modifications under the debian hurd
> running in qemu (debian-hurd-20210219.img), I got the
> following error. ``` socket_fd.cc: In
> member function 'bool
> torrent::SocketFd::set_priority(torrent::SocketFd::priority_type)':
> socket_fd.cc:78:43: error: 'IPV6_TCLASS' was not declared in this scope;
> did you mean 'IPOPT_CLASS'? ```
> and it matches with what that page said. I also try
> to build that package under my debian desktop(Debian GNU/Linux bullseye/sid
> x86_64) and it got no errors. After a quick search, i have found linux
> defined the `IPV6_TCLASS` macro at `bits/in.h` as follows:
> ``` #define IPV6_TCLASS 67
> ``` So that, I modify the `configure.ac` to add a
> conditional compilation when it detects the host operating system is hurd
> based, along with macro definition at the `Makefile.am` found at `src/net/`.
> The patch file is attached at the end of this email.
> But I have some questions: 1. Should I only
> load that patch file? Is it enough? Should I provided a change
> file?2. If the patch file is accepted, how it can be merged to the
> official deb package?3. Should I add some other description
> information to the patch file?4. Can somebody tell me how can I
> become a debian package maintainer? Is there any detailed and practical
> guides? Thank you!
> ---hahawang ---
> a/configure.ac+++ b/configure.ac@@ -1,5 +1,17
> @@AC_INIT(libtorrent, 0.13.8,
> sundell.softw...@gmail.com)
> +AC_CANONICAL_HOST++build_hurd=no++case
> "${host_os}" in+ gnu*)+ build_hurd=yes+
> ;;+esac++AM_CONDITIONAL([BUILD_HURD], [test
> "$build_hurd" =
> "yes"])+LT_INIT([disable-static])
> dnl Find a better way to do this---
> a/src/net/Makefile.am+++ b/src/net/Makefile.am@@ -26,3
> +26,7 @@throttle_node.h AM_CPPFLAGS =
> -I$(srcdir) -I$(srcdir)/.. -I$(top_srcdir)++if
> BUILD_HURD+AM_CPPFLAGS +=
> -DBUILD_HURD+endif---
> a/src/net/socket_fd.cc+++ b/src/net/socket_fd.cc@@
> -50,6 +50,10 @@#include "torrent/exceptions.h"#include
> "socket_fd.h" +#ifdef BUILD_HURD+#define
> IPV6_TCLASS 67+#endif+namespace torrent
> { inline void
Hello,
Please avoid HTML emails (this applies to most open source development
mailing lists).
I suggest you also send to bug-h...@gnu.org, which is the main mailing
list concerning Hurd development.
--
Richard Braun
Re: PHP 7.4 on Debian GNU/Hurd
On Tue, Dec 01, 2020 at 11:39:35AM +, Jessica Clarke wrote: > On 1 Dec 2020, at 11:29, Richard Braun wrote: > > > > Hello, > > > > The php7.4 package and all that depend on it cannot be built because of > > a dependency from php7.4 on systemd. Is there anything that can be done > > about it ? > > Yes; see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951834. I see, thanks. -- Richard Braun
PHP 7.4 on Debian GNU/Hurd
Hello, The php7.4 package and all that depend on it cannot be built because of a dependency from php7.4 on systemd. Is there anything that can be done about it ? Thanks. -- Richard Braun
Re: exec hang at boot.
On Thu, Oct 08, 2020 at 12:16:51AM +0200, Samuel Thibault wrote: > I might have found the trigger for the exec hang at boot. The symptoms > were that very early during the program loading by ld.so, it would > overflow its stack with 0x40, apparently because there were odd things > happening with the GOT. One odd thing was that ld.so was getting loaded > at 0x0. That's because it is a PIE. Issues that might come up are that > pointer 0x0 could then actually be a should-be-valid pointer... I > modified gnumach to load PIE binaries at 0x800, like our exec server > does, and couldn't reproduce the exec hang at boot. This is now in > debian as gnumach version 2:1.8+git20201007-1. Very nice. -- Richard Braun
Vim versions
Hello, I see that vim version is 2:8.2.0439-1 in unstable/main, but vim-common version is 2:8.2.0716-3. How do we deal with this currently ? -- Richard Braun
Re: Bigger disk for preinstalled image?
On Fri, Jan 10, 2020 at 09:31:12AM +0100, Philipp Klaus Krause wrote: > Once or twice per year, I need to use a Debian GNU/Hurd system (I'm an > upstream SDCC developer and want to check that SDCC works well on Debian > GNU/Hurd before releases). > > The preinstalled images are convenient. But after installing the build > dependencies, the 4 GB disk size is too small to full SDCC regression tests. > > Is there an easy way to increase the size of the disk for the > preinstalled image? If using a virtual machine, you could add another disk and format it yourself, then mount it where it suits you and work there. You could resize the 4 GB disk and its partitions, but it's more work and somewhat easy to mess up, which could be destructive, so I don't recommend it. -- Richard Braun
Re: Debian GNU/Hurd 2019 released!
On Sat, Jul 13, 2019 at 08:37:54PM +0200, Arne Babenhauserheide wrote: > > 1. The installer uses ext2. > … > > Regarding (1), ext2 seems a bit unusual in 2019, but it may be a > > design decision. It may be worth noting ext4 is a journaled file > > system and ext2 is not. > > The reason for ext2 is that this is not just an ordinary ext2, but one > which supports setting passive Hurd translators on nodes (started on > access to the filesystem node). The real reason is history. Noone did work to get ext4 in, but ext2 on the other hand was there from the start. How can people imagine this is a design decision at all ? -- Richard Braun
Re: Bug#825975: sysvinit: Add missing poweroff on hurd-i386
On Fri, Jan 11, 2019 at 12:37:16PM +, Dmitry Bogatov wrote: > Dear colleagues, I seek your advice. > > Samuel, as Debian GNU/Hurd user and > Justin, as developer who wrote sysvinit-core.config, > you may be the most knowledgable about issue. > > I am trying to understand, what is the purpose of following code in > sysvinit-core.config: > > if [ "$(uname)" = GNU ]; then > db_set sysvinit/hurd-fix-inittab "true" > if echo '3e3693078d18d4696c83a76531433cd4 /etc/inittab' \ > | md5sum --status --check -; then > # The file is unmodified, update it silently. > : > elif [ $(fgrep -c -e '/libexec/getty' /etc/inittab) -gt 0 ] || \ > [ $(grep -c '^c:' /etc/inittab) -eq 0 ]; then > db_input low sysvinit/hurd-fix-inittab || true > db_go > fi > fi > > What is magic md5 '3e3693078d18d4696c83a76531433cd4'? What is the state > of transition it was intended for? That magic number is the md5 sum of the inittab file intended to be updated. The script makes sure that the inittab content is the one expected before updating it. -- Richard Braun
Re: Need help about choosing MSc thesis
On Fri, Dec 01, 2017 at 04:57:14PM +0330, behnam mohammad karimi wrote: > I want work on HURD for my MSc thesis. So I want some paper about HURD or > kernel development, but I can't find any paper > Can u help me? Do u have any paper? (2015 or later) There hasn't been any paper on the Hurd since the critique [1]. -- Richard Braun [1] http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf
Re: How to identify "running on a Hurd system"?
On Fri, Aug 25, 2017 at 01:56:53PM +0200, Samuel Thibault wrote: > Narcis Garcia, on ven. 25 août 2017 13:38:31 +0200, wrote: > > 1. You are confirming GNU is an operating system, and Hurd is a GNU > > element: Hurd is not whole GNU. > > Yes. > > > 2. Words as "Hurd" or "Mach" are more specific terms than "GNU". > > Yes. > > > 3. GNU is not a kernel > > Yes. > > > $ uname -s > > Should not return "GNU" > > It should. > > POSIX says: > > -s Write the name of the implementation of the operating system. > > The operating system is GNU, so it says GNU. Some bikeshed discussion. It has always been GNU, it won't change. Other systems (will) use something else. Period. -- Richard Braun
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 10:17:47AM +0100, James Cowgill wrote: > I have a feeling it's not an upstream issue. The patch I mentioned above > is only applied in Debian's glibc package. Which is the only one really in use, and maintained by the same people, but for some reason, you have a much better chance on bug-hurd. -- Richard Braun
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 11:10:29AM +0200, Richard Braun wrote: > On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: > > On 28/07/17 09:05, Richard Braun wrote: > > > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > > >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the > > >> "clock" function has a far lower precision on Hurd than it does on > > >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > > >> > > >> I also found this patch to libc which may be responsible: > > >> hurd-i386/unsubmitted-clock_t_centiseconds.diff > > >> > > >> I'm not entirely sure why patching libc is appropriate to fix the > > >> claimed issues. > > > > > > The patch has nothing to do with precision. The kernel simply doesn't > > > have any high resolution timing system, whereas Linux does. > > > > In that case, clock should be returning multiples of whatever precision > > is supported by the kernel so that CLOCKS_PER_SEC is still correct. > > That macro is required by XSI to have this value, as described by POSIX [1]. I replied too quickly. I don't have all the details in mind but you may be right. Please use the bug-h...@gnu.org mailing list to report this issue upstream. -- Richard Braun
Re: Debian Hurd clock precision
On Fri, Jul 28, 2017 at 09:58:54AM +0100, James Cowgill wrote: > On 28/07/17 09:05, Richard Braun wrote: > > On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > >> While debugging a timing problem with FFmpeg on Hurd, I noticed that the > >> "clock" function has a far lower precision on Hurd than it does on > >> Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > >> > >> I also found this patch to libc which may be responsible: > >> hurd-i386/unsubmitted-clock_t_centiseconds.diff > >> > >> I'm not entirely sure why patching libc is appropriate to fix the > >> claimed issues. > > > > The patch has nothing to do with precision. The kernel simply doesn't > > have any high resolution timing system, whereas Linux does. > > In that case, clock should be returning multiples of whatever precision > is supported by the kernel so that CLOCKS_PER_SEC is still correct. That macro is required by XSI to have this value, as described by POSIX [1]. -- Richard Braun [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
Re: Debian Hurd clock precision
On Thu, Jul 27, 2017 at 11:39:21PM +0100, James Cowgill wrote: > While debugging a timing problem with FFmpeg on Hurd, I noticed that the > "clock" function has a far lower precision on Hurd than it does on > Linux, even though CLOCKS_PER_SEC is 100 on both. Why is this? > > I also found this patch to libc which may be responsible: > hurd-i386/unsubmitted-clock_t_centiseconds.diff > > I'm not entirely sure why patching libc is appropriate to fix the > claimed issues. The patch has nothing to do with precision. The kernel simply doesn't have any high resolution timing system, whereas Linux does. -- Richard Braun
Re: unmet dependencies
On Mon, Jan 23, 2017 at 01:08:30AM +0100, Samuel Thibault wrote: > I do use it, and never have problems with it. You do ? My bad :). -- Richard Braun
Re: unmet dependencies
On Sun, Jan 22, 2017 at 10:45:07PM +0100, Riccardo Mottola wrote:
> I upgraded.. and forced install as you said. The system reboots and I can
> login, however I cannot telnet into the virtual machine anymore.
> I always do that since it is much more convenient than the VirtualBox
> console.
>
> When logging in, I notice on the console that something crashes.
>
> /hurd/crash: in.telnetd: 10.0.2.2(744) crashed, signal {no: 11, code:2,
> error:2}, exception {1, code:2, subcode>186128}, PCs {0x34db3, 0x10769ax},
> killing task.
>
> may that be related to an incomplete upgrade or is the new stuff unstable?
It's probably a bug, but since none of use use telnet, it's been overlooked.
But you shouldn't be using telnet either, you should use SSH.
--
Richard Braun
Re: unmet dependencies
On Mon, Jan 09, 2017 at 02:31:34PM +0100, Riccardo Mottola wrote: > I run apt-get update and then upgrade tells me: > > You might want to run 'apt-get -f install' to correct these. > The following packages have unmet dependencies: > gnupg : Breaks: dirmngr (< 2.1.17-2) but 2.1.16-2 is installed > Recommends: dirmngr (= 2.1.17-2) but 2.1.16-2 is installed > Recommends: gnupg-l10n (= 2.1.17-2) but it is not installed > hurd : Depends: hurd-libs0.3 (= 1:0.8.git20161120-1+b2) but > 1:0.9.git20161219-1 is installed > Recommends: bf-utf-source but it is not installed > E: Unmet dependencies. Try using -f. > > > what should I do_ apparently hurds wants an aolder version of hurd-libs, but > the last time I upgraded, the system was consistent. What does apt-get dist-upgrade tell you ? -- Richard Braun
Re: gnumach memory attributes
On Sun, Nov 20, 2016 at 01:09:08PM +0100, Luca dariz wrote: > Maybe the translation should be done by the pager? > For example, the default pager would deny such requests, while there > could be an "io pager" which handles only contiguous memory objects and > perform the translation. We don't want pagers, privileged or not, to mess with page tables. These are the responsibility of the kernel. > The main reason of this distinction is that sometimes on rump drivers > the buffer used for I/O is not allocated from contiguous memory. Which is fine. You're not dealing with just contiguous memory here, you want to handle any device memory. > Ok, so memory mapped I/O would work for user-space drivers. > I still have to figure out how this "io pager" should be implemented. > Should it be driver-specific? Or should it ask the specific driver to > fill a specific memory page on demand? It should probably driver-specific, but unless you can cite one example where the memory object pattern doesn't fit, I don't think we need a new RPC. What drivers need to do is request specific physical memory to insert into memory objects, with special properties (uncacheable, wired, etc...), that can then be mapped by users. -- Richard Braun
Re: gnumach memory attributes
On Sat, Nov 19, 2016 at 02:37:45PM +0100, Luca dariz wrote: > I was thinking about what kind of memory addresses should be allowed to > be translated to physical addresses from user-space drivers, for example > based on rump kernel. > Obviously memory allocated with vm_allocate_contiguous from dde patch, > so from the DIRECTMAP segment and of type VM_PT_KERNEL. Are there other > possibilities or other parameters to check? The two major types of memory are anonymous and "file", where file means that a memory object isn't backed by the default pager. These shouldn't be affected by what you're trying to do. Other than that, device memory can easily become driver-specific. And by the way, please ignore the VM_PT_XXX types, they're not actually used. > I am thinking about adding an rpc to handle vitual to physical > translations (instead of using the debug interface) and maybe rework the > vm_allocate_contiguous rpc to not give the physical address, making it > similar to vm_allocate. What we'd rather have is something like hugetlbfs, where contiguous physical memory is backed by a pager (probably in the kernel), and applications would use vm_map to get access. -- Richard Braun
Re: way to proceed
On Thu, Sep 15, 2016 at 03:30:51PM +0200, Ola Ekström wrote: > Suppose I find out why one of the failed packages won't build, how do > I proceed? Do I post a patch on the bugtracker? Or here? Or do I > perhaps take some totally different action? I'm not a Debian Developer, but I guess you could post the patch on the (Debian) bugtracker, unless you think upstream is likely to process Hurd-related patches (good luck with that, but it happens). Sorry for the late reply. -- Richard Braun
Bug#836428: hurd, initscripts: /tmp cleaning deletes files through a firmlink
On Sat, Sep 03, 2016 at 01:12:27AM +0300, Kalle Olavi Niemitalo wrote: > Richard Braun <rbr...@sceen.net> writes: > > > This was famously shown with the example of the > > firmlink translator used in /tmp, which would cause the removal of > > any file targeted by the firmlink on /tmp cleanup during system > > startup. > > That was already fixed in daemons/rc.sh as Debian bug #39925 > (hurd: /libexec/rc waits for /tmp/* translators), likely in > version 19990714 of the Debian hurd package. The bug has been > reintroduced: although the fixed script is still installed > (now as /etc/hurd/rc), it is no longer run by default. Instead, > /lib/init/bootclean.sh in the initscripts package cleans /tmp. > > I don't see an open bug report about this in the hurd or > initscripts package, and #39925 has been deleted, > so I'm filing a new one now. Thanks for that. But you do understand that it's not a fix, right ? It's just a hack. A true fix would mean we provide the same assumptions the init scripts on Unix. -- Richard Braun
Re: Debian Hurd installer fixed since 2014?
On Thu, Sep 01, 2016 at 09:23:07AM +0100, Jonathan de Boyne Pollard wrote: > The last time that I tried Debian Hurd, I couldn't even get it installed. > The machine that I was installing on had no network interfaces and didn't > need mail, so I told the Debian installer not to install any networking > stuff at all and that it had no network interfaces, un-checking all of the > checkboxes for mail and the like. The Debian installer dutifully hung > partway through the install, saying that it was configuring exim. Note that installing a mail transfer agent on an isolated system actually makes sense. It's one way between local users to communicate, and it's used by apt to notify you about some important changes when you install/upgrade packages. Besides, it's a pure Debian thing, unrelated to the Hurd. -- Richard Braun
Re: Problems when booting Debian-Hurd
On Sat, Aug 20, 2016 at 01:19:28AM +, Horacio Castellini wrote: > WARNING: Image format was not specified for 'debian-hurd-20150320.img' and > probing guessed raw. > Automatically detecting the format is dangerous for raw images, > write operations on block 0 will be restricted. > Specify the 'raw' format explicitly to remove the restrictions. Check the integrity of the image you've downloaded. -- Richard Braun
Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv
On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote: > Richard Braun <rbr...@sceen.net> writes: > > Why not start the translator from the remapped environment too ? > > No reason, but this has to be implemented. I started working on a > library for writing such chrooting translators, then got side-tracked by > the complexity of the dir_lookup operations. Currently, remap has a > very naive lookup function, fakeroot's is better, but still not > sufficient. I made some patches towards unifying and refactoring the > logic used in libdiskfs and libnetfs, but these functions are still huge > :/ No, i mean, here, in such a specific case, if the parent translator is itself running from the remap env, it should used the custom pflocal instance, right ? -- Richard Braun
Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv
On Mon, Aug 08, 2016 at 12:55:24PM +0200, Justus Winter wrote: > Right, I can see how this is a problem. The thing is, remap doesn't > quite do the job: 1/ it fails to remap relative paths, 2/ if one sets a > translator record on a node, and that translator is then started by the > filesystem, it is started "outside" of the remap environment. I belive > 2/ is what happens here. Why not start the translator from the remapped environment too ? -- Richard Braun
Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv
On Sun, Aug 07, 2016 at 08:44:56PM +0300, Esa Peuha wrote: > > PS: Is there any way to sanely restart /hurd/pflocal without > > rebooting? > > Yes, the commands to do that are > > settrans -ck /servers/socket/1 > settrans -ck /servers/socket/1 /hurd/pflocal I suggest you don't do that, since you'll basically replace the pflocal instance for all the system, which might break already running processes. Use the remap translator instead, which is one of the things the Hurd design allows you to do easily. See /bin/remap to easily set one. -- Richard Braun
Re: open-isns porting question: sudden SIGLOST
On Sun, Jul 24, 2016 at 03:16:36PM +0200, Christian Seiler wrote: > Peculiarities: the code uses SCM_CREDS and sendmsg/recvmsg over the > local UNIX socket to check authorization. (Since there's no man page I > could find about it, I assume that SCM_CREDS is implemented in the same > way that kFreeBSD does it, at least if I look at the system header > files.) Please correct me if I'm wrong, but I'm almost certain we don't support SCM_CREDS yet. -- Richard Braun
Re: Hello World!!
On Sun, May 22, 2016 at 06:58:29PM +, Gage Morgan wrote: > Okay I found a building page on the site. I'm going to try and figure it out. > I just found out that I can get the packages using apt-get source > package-name-here and then rebuild on an x86-64 build. If I manage to get a > resulting image, I'll place it in a repo at > https://github.com/Christoffen-Corporation. The Debian folks are welcome to > use it. Before you rush, take some time to talk to the upstream developers. We already have a 64 bits branch, and we know what to do and how, we just, as usual, lack the manpower. The upstream mailing list is bug-h...@gnu.org. We also communicate a lot on IRC (#hurd @ freenode). See our wiki on how to contribute [1] and take a look at the work already done [2]. -- Richard Braun [1] https://www.gnu.org/software/hurd/contributing.html [2] http://git.savannah.gnu.org/cgit/hurd/gnumach.git/log/?h=master-x86_64
Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support
On Mon, Mar 14, 2016 at 02:35:13PM +0100, Svante Signell wrote: > On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote: > > On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote: > > > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote: > > > > Why, because it doesn't have a sleep statement? > > > > > > I was referring to strict logic: it's not just because it happens to > > > > Also, using sleep for synchronization is always wrong. > > Dear Richard and Samuel, I know using sleep is considered bad! Please tell me > how the test code should be written to wait for the acknowledgement from the > receiver. That would be more productive than complaining :) Read a book or go to school. -- Richard Braun
Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support
On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote: > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote: > > Why, because it doesn't have a sleep statement? > > I was referring to strict logic: it's not just because it happens to Also, using sleep for synchronization is always wrong. -- Richard Braun
Re: virtio support
On Tue, Feb 09, 2016 at 02:29:10PM +0100, Svante Signell wrote: > And to recheck the root partition from GNU/Linux: > su > Password: > /sbin/losetup -o 1048576 /dev/loop0 hurd.img > e2fsck -y -b 32768 /dev/loop0 > > (offset = 1048576 = 2048*512 if first partition starts at 2028, see > /sbin/fdisk > -lu ./hurd.img) Use either losetup -P, or partx if your losetup version doesn't support -P. And don't force the superblock location. -- Richard Braun
Re: virtio support
On Tue, Feb 09, 2016 at 07:09:16PM +0530, Ritesh Raj Sarraf wrote: > I think I'm just having a bad time. :-( The Hurd is quite unstable and many small errors can force a reset and file system checking. Most of us know the tricks but it could be a good thing to document them on the wiki though. -- Richard Braun
Re: (was: Small web server for the Hurd)
On Mon, Jan 11, 2016 at 04:56:31PM +0100, Thomas Schwinge wrote: > Hi! > > On Sun, 22 Nov 2015 01:01:09 +0100, Richard Braun <rbr...@sceen.net> wrote: > > It looks like some changes in the past months have increased the > > severity of some bugs apache is having when spawning CGIs, resulting > > in unkillable processes and the freezing of the parent apache process. > > This had the effect of making the darnassus.sceen.net server almost > > unusable publicly. > > :-/ FYI, the problem still occurs, although much less frequently. I assume there is a race issue with exec/fork. The tough part is that SIGKILL is unable to kill those bogus child processes, forcing a complete system reset. -- Richard Braun
Re: PATCH: Hurd FTBFS with perl 5.22
On Mon, Jan 04, 2016 at 11:09:00PM +0100, Svante Signell wrote:
> On Mon, 2016-01-04 at 22:50 +0100, Samuel Thibault wrote:
> > Svante Signell, on Mon 04 Jan 2016 22:02:02 +0100, wrote:
> > > - @val = @{$canned_values{$hz}};
> > > - if (!defined(@val)) {
> > > - @val = compute_values($hz);
> > > - }
> > > + @val = compute_values($hz);
> >
> > Don't we want to still try to use canned_values?
>
> As I wrote in IRC you should solve this, not me. Obviously the !defined(@val)
> is
Apparently you're too stupid to notice when you lack respect, so we'll
tell you.
Don't.
--
Richard Braun
Small web server for the Hurd
Hello, It looks like some changes in the past months have increased the severity of some bugs apache is having when spawning CGIs, resulting in unkillable processes and the freezing of the parent apache process. This had the effect of making the darnassus.sceen.net server almost unusable publicly. Since I don't have the time to hunt that bug, I decided to replace the web server, and unfortunately, the already packaged ones are either non fonctional, or don't build on the Hurd. As a result, I have packaged the small thttpd web server, or more precisely, its sthttpd fork. The result is available at the darnassus git repository [1]. The Debian stuff I did is certainly not perfect and I welcome patches. Binary and source packages are also available from my Debian repository (which still uses the legacy format) : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ deb-src http://ftp.sceen.net/debian-hurd-i386 experimental/ The only negative consequence I can see is that URLs that relied on URL rewriting are now invalid, since it's not implemented by this web server. -- Richard Braun [1] http://darnassus.sceen.net/gitweb/
Debian ports mirror setup
Hello, I'm currently in the process of setting up a Debian ports mirror for the hurd-i386 arch since it's going to be removed from the main Debian repository. Has this been done already ? If not, when is it planned ? How large do you think the complete repository (for hurd-i386 and sources only) would be ? Thanks. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150720223502.GA4445@shattrath
Re: Debian hurd porter boxes
On Fri, May 29, 2015 at 10:15:00AM +0530, Samuel Thibault wrote: Well, actually it's the dom0 which pings, exodar is a domU which is usually shut down since it's so slow. Name confusion ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150529084326.ga27...@dalaran.sceen.net
Memory management GSoC progress
Hello, As part of the Google Summer of Code (GSoC) 2015, Justus Winter started working on replacing the IPC space data structure. He merged radix tree code into GNU Mach, completely removed the old hash table/splay tree based code, and made IPC spaces use radix trees instead, which implied walking over many tricky inline versions of small IPC functions, historically intended to increase performance on the IPC path when compilers were bad at inlining. The result is a strong decrease in fragmentation inside the kernel memory pool. This was the main goal of reworking IPC spaces. But as a nice side effect, there is also an increase of overall performance of about 5-10%. We expect this is caused by removing reverse IPC hash tables that were previously incorrectly tuned. I made Debian packages available on my repository for testing : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ deb-src http://ftp.sceen.net/debian-hurd-i386 experimental/ This code is currently being polished and should be merged soon into the main gnumach repository. -- Richard Braun [1] https://www.google-melange.com/gsoc/project/details/google/gsoc2015/teythoon/588030830336 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150519124435.ga2...@dalaran.sceen.net
Re: Gnumach 1.5
On Sun, May 17, 2015 at 11:21:55AM -0400, Jose Luis Alarcon Sanchez wrote: Is there a way of install the 1.5 version of Gnumach from the Debian package system?. I use Debian GNU/Hurd 8 with GNU-Mach 1.4+git20150409-486, and maybe Gnumach 1.5 have some improves. Is there, at least, a place where get the binary file of the microkernel?. You can either wait for the package, or build it yourself. I build it from the source code, apparently with success, but a strange thing happen at boot time: I run Hurd on qemu-kvm and i set the virtual machine with 1024 Mb. of RAM. No problem with the default gnumach-1.4, but with the gnumach-1.5 i build, the RAM is restricted to 831 Mb. Look at the Debian patches. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150517100529.ga3...@dalaran.sceen.net
Re: Debian Archive architecture removals
On Mon, Apr 20, 2015 at 02:21:00PM +0200, Zlatan Todoric wrote: Really?! So Hurd actually has a sufficient number of developers worldiwde?! And if Devuan is so welcome and Debian so hostile, more power to them, I just don;t know what are you waiting here and polluting our ML with toxic tone! I suggest you do what I do: ignore mails from Svante. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505123059.ga27...@dalaran.sceen.net
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 01:36:57PM +0200, Arne Babenhauserheide wrote: Given that the package coverage of the Hurd continuously increased and that it just released 0.6 of its core components[1] along with releasing Debian GNU/Hurd[2], this strikes me as an odd time to throw the Hurd off ftp-master. It's irrelevant. The Hurd isn't a popular system, few people actually use it, there are probably a lot more Debian mirrors than machines using them with hurd-i386 packages. It's simply not worth it. I'm not a Debian contributor but, as a Hurd contributor, it seems perfectly appropriate that the Hurd gets removed from there. On the other hand, I'm ready to provide resources so that things work nicely from debian-ports. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505122710.ga31...@dalaran.sceen.net
Re: Debian Archive architecture removals
On Tue, May 05, 2015 at 09:17:02AM +0200, Samuel Thibault wrote: [Speaking for the debian-hurd team] Lucas Nussbaum, le Mon 04 May 2015 08:28:22 +0200, a écrit : Maybe it's just about supporting and advertising debian-ports as Debian's official way to host second-class architectures. Maybe there's more to it. What are the current downsides of moving hurd-i386 and sparc to debian-ports? That's perhaps the best question to address. Being on master just for being mirrored is not useful to such kinds of ports of course. In the current status of the Debian infrastructure, there are however a lot more consequences, which we can perhaps work on, so as to avoid making hurd-i386 and sparc essentially disappear, and perhaps at the same time to revive some debian-ports archs without overhead for ftp-master, d-release etc.. Also perhaps more easily consider removing more archs from master. I completely agree. And I also agree that moving to debian-ports makes patches harder to get merged, but if debian-ports becomes something more official, it may get slightly easier. Perhaps we need a political decision here? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150505123552.gb27...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote: I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Iceweasel 36.0-2 (from experimental) is available. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150304133043.ga2...@dalaran.sceen.net
Re: e2fsck of non-root filesystem failing at boot time, because already mounted?
On Sat, Feb 21, 2015 at 12:04:36AM +0100, Justus Winter wrote: $ showtrans /media/erich /hurd/ext2fs --no-atime /dev/hd2 $ grep hd2 /etc/fstab /dev/hd2/media/erich ext2 defaults 0 2 That's odd. Though I must admit I do not use passive translator records to mount disks. Maybe the Debian init scripts just aren't compatible with that. Personally I'd be ok with that. Don't mix fstab with passive translators. The init scripts actually do mount fstab entries now. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150220232205.ga29...@dalaran.sceen.net
Re: A bittorrent version of the Hurd DVD?
On Tue, Oct 14, 2014 at 03:15:45PM +0530, Rajib Bandopadhyay wrote: I need a bittorrent version of the Hurd DVD? Couldn't find one, which keeps me from experimenting with hurd. Please advise. Have an unreliable connection topped with power-cuts. The DVD is also unreliable, because of issues with regard to filesystem size in the iso9660fs translator. The recommended approach is using the network installer [1]. -- Richard Braun [1] http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debian-hurd-2013-i386-NETINST-1.iso -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015104532.ga25...@dalaran.sceen.net
Re: Processor Support?
On Tue, Sep 23, 2014 at 06:57:05PM -0700, Omar Radwan wrote: I'm wondering if it is possible to run Debian HURD on AMD hardware, or Intel hardware such as i3, i5, and i7. But isn't guarantee that it runs on Pentium. First, you should ask this on bug-hurd, this question doesn't directly concern Debian. As for the question itself, the Hurd runs on i386 compatible hardware, so Intel (including Pentium) and AMD processors are supported. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140927095858.ga22...@dalaran.sceen.net
Re: Error in 2 packages
On Mon, Sep 22, 2014 at 04:16:17PM +0300, ** wrote: Do you know if the problem will be fixed if I erase and reinstall the 2 packages? Little help please... Probably not. Note that : 1/ We need more details about what you're trying to do. 2/ The Hurd has a small user base, so you're likely to discover problems on your own, and looking for solutions by yourself will be your best tool to solve them. I'm not saying you shouldn't ask for help, but you just shouldn't wait passively for it to come. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140922134547.ga8...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Tue, Sep 16, 2014 at 11:18:04PM +0800, Zhang Cong wrote: @Mike, what things need to do to make this work upstream, as we talked in, Zhang, please don't take it wrong, but it's not your business. You didn't do the work, you didn't actually contribute to anything yet, don't try and boss other people. Mike will handle the bug when he decides to, and I'll keep providing packages in the mean time. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916152826.ga18...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote: I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Iceweasel 31.1.0esr-1 (from unstable) is available. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915183144.ga14...@dalaran.sceen.net
Bug#760427: netdde: gets often stuck using pcnet driver
On Thu, Sep 04, 2014 at 02:26:00AM +0200, Gabriele Giacone wrote: By switching card to e1000, it works fine, no hangs with heavy network traffic so far. This is probably just pure luck. There are known issues unrelated to the driver in netdde, probably caused by the condition/mutex code which was reused from a previous version of libpthread. In particular, see the various TODOs and FIXMEs in libddekit [1]. These should probably be reworked to use the libpthread facilities directly. -- Richard Braun [1] http://anonscm.debian.org/cgit/pkg-hurd/hurd.git/tree/libddekit/thread.c -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140904004420.ga2...@dalaran.sceen.net
Re: Small test example for: cannot create /dev/null: Interrupted system call
On Mon, Jul 07, 2014 at 01:29:20PM +0200, Svante Signell wrote: ./test.sh: 6: ./test.sh: cannot create /dev/null: Interrupted system All right, it looks like open() gets interrupted by SIGCHLD here. It's my understanding that signal handling is highly system-specific in such cases, but we probably want to align on what others do, as usual. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710211817.ga18...@dalaran.sceen.net
Re: Small test example for: cannot create /dev/null: Interrupted system call
On Thu, Jul 10, 2014 at 02:21:06PM -0700, Roland McGrath wrote: Is the SIGCHLD set with SA_RESTART? From what I see, no. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710212508.ga19...@dalaran.sceen.net
Re: Small test example for: cannot create /dev/null: Interrupted system call
On Thu, Jul 10, 2014 at 11:18:17PM +0200, Richard Braun wrote: All right, it looks like open() gets interrupted by SIGCHLD here. It's my understanding that signal handling is highly system-specific in such cases, but we probably want to align on what others do, as usual. By the way, it looks like it happens with dash only, not bash. I suppose dash relies on the Linux-specific behaviour of interrupting a blocked open(). See if switching to bash helps. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140710212624.ga20...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote: I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Iceweasel 30.0-2 (from unstable) is available. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140621200529.ga22...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote: I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Iceweasel 29.0.1 (from unstable) is available. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140514205520.ga9...@dalaran.sceen.net
Re: Hurd support in libpcap
On Thu, Apr 10, 2014 at 02:01:17AM +0200, Richard Braun wrote: The first issue that can be noticed is that, despite the filter being filled with both NETF_IN and NETF_OUT, only incoming packets seem to be captured. This is probably a minor bug in libbpf but I didn't investigate yet. The issue seems to be in libmachdev, which simply doesn't forward sent packets to any packet filter. Is there a reason why libmachdev is only built statically ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140411094247.ga3...@dalaran.sceen.net
Re: Cleaning up dde for the Hurd (was: Hurd support in libpcap)
On Fri, Apr 11, 2014 at 03:13:02PM +0200, Justus Winter wrote: This is most likely just an oversight. I started going over the dde code. Zheng Da got lot's of little details wrong. This is not meant to sound harsh, I'm full of respect that he got dde-based drivers up and running during a gsoc. Agreed. Now let's team up and clean up his work so that we can merge it upstream and have a good template for more dde-based drivers :) It won't be easy and I'll probably won't have time to do much about it, for a change... But at least, I'm currently working on fixing locking on packet filters and actually relaying sent packets so that packet capture works. Note that this may slightly reduce performance because of the way filters work, i.e. a net_msg must be completely forged, with memory copies, before being sent to packet filters, even if there is no filter installed. If someone wants to work on optimizing this, feel free to do it, but please mind the details because that's where the tricky bugs will come from. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140411140348.ga24...@dalaran.sceen.net
Hurd support in libpcap
Hello, A while ago, I added support for Hurd (actually Mach) network devices in libpcap. I've refreshed this work so that it now tries to fetch data from netdde before trying a Mach device, just like pfinet does. Debian packages built with the patch [1] are available from my repository for tests : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ deb-src http://ftp.sceen.net/debian-hurd-i386 experimental/ The first issue that can be noticed is that, despite the filter being filled with both NETF_IN and NETF_OUT, only incoming packets seem to be captured. This is probably a minor bug in libbpf but I didn't investigate yet. -- Richard Braun [1] http://darnassus.sceen.net/~rbraun/0001-Debian-GNU-Hurd-with-NETDDE-support.patch -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014041117.ga5...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Thu, Feb 27, 2014 at 10:17:07PM +0100, Richard Braun wrote: I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Iceweasel 28.0-1 and NSPR 4.10.4 are now available. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140408092218.ga28...@dalaran.sceen.net
Re: Leaving the Debian GNU/Hurd packaging team
On Thu, Mar 06, 2014 at 03:47:20AM +0100, Guillem Jover wrote: I probably will still be lurking around, and might show up in the upstream lists or here from time to time, though. Thanks for your help :). -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2014030716.ga20...@dalaran.sceen.net
Re: Recent version of Iceweasel along with fixes
On Sat, Mar 01, 2014 at 12:13:18PM +0800, Zhang Cong wrote: 1. Crash once for clipboard assert=NULL?, I lost the detail. Please try to reproduce, or at least give more details about what you did before the crash occurred. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140305234348.ga23...@dalaran.sceen.net
Recent version of Iceweasel along with fixes
Hello, I've started working on porting more recent versions of Iceweasel (our binary packages are from version 17), and fixing some important issues at the same time. The current status is that packages are available for version 27.0-2, and all major bugs have been fixed. I have reliably used it for several days straight, without terminating the test processes, with many tabs, with custom GTK themes, IPv4/IPv6 sites, SSL/TLS, and even SWF applets through Gnash. I consider that reliable enough for practical use, although the lack of acceleration and sound will make watching videos a bit frustrating at times ;-). The thread-safety issues that would lead to random crashes have been fixed in libc0.3 2.18-1. The SSL/TLS issue is addressed in a patch attached to bug #739658 [1]. The Iceweasel FTBFS issues themselves are still being worked on until I'm satisfied with the result. The patch fixing them can be found in the source packages on my personal repository, along with the binary packages for Iceweasel and nspr : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ deb-src http://ftp.sceen.net/debian-hurd-i386 experimental/ I intend to regularly update these packages to track the experimental branch until the changes are merged in the official repository. Enjoy. -- Richard Braun [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=0001-Define-_PR_HAVE_SOCKADDR_LEN-for-the-Hurd.patch;att=1;bug=739658 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140227211707.ga27...@dalaran.sceen.net
Re: New glibc
On Fri, Feb 21, 2014 at 06:22:13AM -0800, Samuel Thibault wrote: libc 2.18 has just been uploaded. It notably includes Richard's fix for thread resources and name resolution fix for iceweasel. We'll have to update hurd packages so that hurd servers actually benefit from thread destruction. In the meantime, packages for both the hurd and iceweasel are provided on my repository : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140223043418.ga25...@dalaran.sceen.net
Re: Should _POSIX_TIMERS be set to 200809L instead of 0?
On Tue, Feb 18, 2014 at 11:55:07PM +0100, Svante Signell wrote: Quoting: This is a completely illegal and non-sensical combination. POSIX requires timers if clock selection is supported, since clock selection instrinsically depends on timers. Furthermore POSIX.2008 requires timers and the monotonic clock in any case (they are *not* optional). So as already implied, your system is broken. It is your operating system, not VLC, that needs fixing. However from http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap02.html one reads (quote): * The following symbolic constants shall be defined by the implementation as follows: o Symbolic constants defined with the value 200809L: _POSIX_CLOCK_SELECTION ... _POSIX_TIMERS ... * The system may support one or more options (see Options) denoted by the following symbolic constants: _POSIX_MONOTONIC_CLOCK Who is right? I'd say you are. _POSIX_MONOTONIC_CLOCK is indeed optional and not implied by _POSIX_CLOCK_SELECTION. It merely states that CLOCK_MONOTONIC is supported. Whether it makes sense to be able to select a single clock is another topic... -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218232711.ga10...@dalaran.sceen.net
Re: Avoid upgrading to apt 0.9.15.1
On Sun, Feb 09, 2014 at 08:03:25PM +0100, Samuel Thibault wrote: Hello, You should avoid upgrading your apt package to 0.9.15.1: it unconditionally uses futimens, which is not supported on hurd-any, and apparently not on kfreebsd-any either. Since glibc has been upgraded to support the missing interface (in package version 2.17-98~1), it is now safe to upgrade apt as well. Thanks for the fast fix. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140213000852.ga13...@dalaran.sceen.net
Re: GNU/Hurd DDE talk at FOSDEM
On Fri, Jan 31, 2014 at 01:06:53AM +0100, Samuel Thibault wrote: On sunday afternoon, I will talk about DDE at FOSDEM. I'm now wondering: what is interesting to talk about on DDE, btw? How IOMMU can add value on a multiserver system maybe ? But that's not specific to the Hurd. Or perhaps how tools that seem specific to Linux such as RCU can be reliably wrapped on a system that doesn't provide them. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140131113813.ga27...@dalaran.sceen.net
Re: installing a DM in the qemu image?
On Thu, Jan 30, 2014 at 10:36:12AM +0100, Samuel Thibault wrote: Do people think we should include a DM by default, i.e. X automatically started by the qemu image? No, users can install one on their own, and it makes no sense for the more common use as an ssh server we make of it. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140130125946.ga10...@dalaran.sceen.net
Re: Using cthreads
On Thu, Jan 23, 2014 at 07:10:19AM +0100, Thomas Schwinge wrote: Even though deprecated, it should still be working without any tweaks, as far as I know. No, it became a stub only, to make sure libpthread was correctly replacing it and force its use afterwards. We should remove the last references in glibc but there are other priorities, as always :-). -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140123094620.ga28...@dalaran.sceen.net
Re: X error -- Cannot open keyboard (Not a directory)
On Fri, Jan 10, 2014 at 09:02:24PM +0800, Zhang Cong wrote: I have report this as xkb-data bugs, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734764 , /usr/share/X11/xkb/compat/default was missing. Fixed the first of January in the Debian hurd repository, see : http://anonscm.debian.org/gitweb/?p=pkg-hurd/hurd.git;a=commitdiff;h=d0e5646eb5649293592904d4507e5cba6812d0b0;hp=29d4c2d2bb9c320e25f62717d2fabb31498e2f36 The next hurd packages will include the patch. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140110131801.ga21...@dalaran.sceen.net
Re: process table hurd-i386
On Mon, Jan 06, 2014 at 10:57:07PM +, Bas van den Dikkenberg wrote: Can some help me answer this so we can make this work ? http://pgfoundry.org/tracker/index.php?func=detailaid=1011201group_id=1000300atid=1127 Well, the error looks quite obvious : configure: error: System type gnu unrecognized What process table uses hurd-i386 same normal linux ? What do you mean with process table ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107220853.ga23...@dalaran.sceen.net
Re: process table hurd-i386
On Tue, Jan 07, 2014 at 10:11:46PM +, Bas van den Dikkenberg wrote: If take look at source of ptop look at machine directory you see what i mean The Debian Hurd packages do provide a proc file system mostly compatible with that of Linux, which you may indeed want to try first. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107222739.ga27...@dalaran.sceen.net
Re: [RFC] Enable thread termination
On Sun, Nov 17, 2013 at 05:13:23PM +0100, Richard Braun wrote: The following changes actually apply to Debian eglibc 2.17-96 sources, Binary packages are available for testing on my repository : deb http://ftp.sceen.net/debian-hurd-i386 experimental/ Install gnumach first, then glibc, then the Hurd. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131118094152.ga7...@dalaran.sceen.net
Re: Fully TLS libc
On Tue, Nov 12, 2013 at 02:42:29PM +0100, Samuel Thibault wrote: This morning, a libc with fully TLS variables was uploaded. It means libpthread and makecontext can now accept any kind of stack (size and alignment). We should also be able to now implement SA_ONSTACK. Actually, the upload looks incomplete. I could find nex libc-bin, locales and multiarch-support packages, but not the new C library itself. In addition, when I try to build it, the build apparently fails at the check-execstack test. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113092235.ga31...@dalaran.sceen.net
Re: Fully TLS libc
On Wed, Nov 13, 2013 at 10:34:13AM +0100, Samuel Thibault wrote: Richard Braun, le Wed 13 Nov 2013 10:22:35 +0100, a écrit : Actually, the upload looks incomplete. I could find nex libc-bin, locales and multiarch-support packages, but not the new C library itself. ?? hurd:~# apt-cache policy libc0.3 libc0.3: Installed: 2.17-94 Candidate: 2.17-95 Version table: 2.17-95 0 500 http://debian.ens-cachan.fr/ftp/debian/ unstable/main hurd-i386 Packages *** 2.17-94 0 500 file:/usr/src/repo/ ./ Packages 100 /var/lib/dpkg/status 2.17-7+hurd.1 0 500 ftp://ftp.debian-ports.org/debian/ unreleased/main hurd-i386 Packages I'll check again, this must probably be a problem on my side. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113093914.ga2...@dalaran.sceen.net
Re: Fully TLS libc
On Wed, Nov 13, 2013 at 10:39:14AM +0100, Richard Braun wrote: I'll check again, this must probably be a problem on my side. Looks like there is a problem with libpthread-stubs. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113110142.ga22...@dalaran.sceen.net
Re: Fully TLS libc
On Wed, Nov 13, 2013 at 01:17:40PM +0100, Samuel Thibault wrote: libpthread-stubs is supposed to have gone away. Nothing seems to force its uninstallation, and libc0.3 isn't upgraded while it's present. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113133126.ga19...@dalaran.sceen.net
Re: llvm / clang / scan-build of the Hurd
On Fri, Oct 25, 2013 at 02:32:08PM -0700, Roland McGrath wrote: Clang does not support nested functions [1], and there is no plan to support them upstream. As such, any file that uses nested functions (or any gcc extension not supported by clang) is excluded from the analysis (see e.g. [2]). Richard has no special love for them, iiuc b/c the semantic is not too well defined. I propose to deprecate their use for the Hurd and to gradually rewrite the code that uses them, That's a non-starter. They are an excellent extension and their semantics are thoroughly well-defined. Unless I'm mistaken, their semantics imply executable stacks, which is great for security, and they don't bring anything we couldn't do with regular callbacks, except adding indentation levels, which is also great for code clarity, in addition to being the most painful GNU extension to implement in other code-related tools like static analyzers. In other words, we don't really need them, they increase security risks, and they prevent us from using nice tools. The real problem with deprecating them is that some function pointers used by glibc code, such as demuxers used by mach_msg_server_timeout, can't easily be modified to take a generic void * pointer without breaking the ABI. Those function pointers were intended to be nested functions from the start. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131104111305.ga22...@dalaran.sceen.net
Re: Help with testing Hurd support patch for PHP
On Tue, Oct 22, 2013 at 01:53:32PM +0200, Lior Kaplan wrote: Any idea? I want to make sure PHP5 doesn't FTBFS on hurd. I haven't followed the discussion completely, but this error looks pretty obvious : error: 'PATH_MAX' undeclared (first use in this function) You can either keep the workaround in that patch, or fix PHP so that it doesn't use PATH_MAX. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131022115743.ga18...@dalaran.sceen.net
Re: CPU % disappears after hurd-0.5 update
On Sun, Oct 13, 2013 at 12:27:05PM +1100, James Haggerty wrote: jamesh@gurdy:~$ top Error, do this: mount -t proc proc /proc Double check the passive translator on /proc. Unrelated: does your recent patch fixes the 'wow, now I have 30 mtab processes' problem? Yes. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131013100922.ga26...@dalaran.sceen.net
Re: CPU % disappears after hurd-0.5 update
On Sun, Oct 13, 2013 at 09:42:30AM +1100, James Haggerty wrote: Just did an apt-get update, apt-get upgrade, and everything seemed to go smoothly except that top now crashes and htop doesn't show cpu %. I'm assuming /proc has started to deliver something funny. I set it up before the update like this: sudo settrans -fgap /proc /hurd/procfs -c So maybe I broke it. Any ideas? Not sure why it hasn't been done, but you actually need to tell procfs the PID of the kernel task now, so something like this : settrans -g /proc /hurd/procfs -c -k 3 On the plus side, /proc/mounts is now delivering something (thanks, mtab!), though df wants to find out how much space is free on /dev/cons for some reason. df looks at /proc/mounts, which is implemented by the mtab translator, which recursively asks for translator information. Not all of them are regular file systems. Also, it doesn't work on /home (or any passive translator yet), be patient, these will get fixed eventually. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131013000245.ga17...@dalaran.sceen.net
Re: Weekly report (14th week) - Debian GNU/Hurd Debianish initialization
On Mon, Sep 23, 2013 at 01:38:26PM +0200, 4win...@informatik.uni-hamburg.de wrote: It has been a lot of fun and I will definitively see you around :) Congratulations, well done indeed. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130923123743.ga10...@dalaran.sceen.net
Re: Newer hurd package
On Wed, Sep 18, 2013 at 12:55:53PM +0200, Justus Winter wrote: That's weird. Care to share cat /proc/mounts? Same issue on darnassus : $ cat /proc/mounts /dev/hd0s1 / ext2fs writable,no-inherit-dir-group,store-type=typed 0 0 none /servers/socket/26 /hurd/pfinet interface=/dev/eth0,address=46.105.42.110,netmask=255.255.255.0,gateway=46.105.42.254,address6=2001:41d0:8:8dd8::110/64,address6=fe80::200:83:cc3c/10,address6=fe80::ff:fe83:cc3c/10 0 0 /dev/ttyp1 /dev/ttyp1 /hurd/term name,/dev/ptyp1,type,pty-master 0 0 /dev/ttyp2 /dev/ttyp2 /hurd/term name,/dev/ptyp2,type,pty-master 0 0 /dev/ttyp0 /dev/ttyp0 /hurd/term name,/dev/ptyp0,type,pty-master 0 0 none /dev/cons /bin/console defaults 0 0 Nice work Justus :) +1, nicely done. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130918120814.ga28...@dalaran.sceen.net
Re: make /hurd/proc run as PID 3, do not use PID 0
On Mon, Sep 16, 2013 at 12:41:19PM +0200, Samuel Thibault wrote: Justus Winter, le Mon 16 Sep 2013 12:20:24 +0200, a écrit : Richard asked me to make /hurd/proc run with a PID other than 0 because that causes various problems. What kind of problem for instance? (at least for the record) Nothing major, I'd simply like this process to be as visible as the rest of the system. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130916115417.ga18...@dalaran.sceen.net
Re: [PATCH] Make start_code and end_code available in /proc/*/stat
On Thu, Aug 29, 2013 at 12:05:30PM +0200, Justus Winter wrote: Quoting Samuel Thibault (2013-08-29 00:24:59) Mmm, I'm not sure whether we really want to introduce proc_set_code/proc_get_code just for killall5. We could just put 0x0800 / 0x0900 values for non-essential processes. What do you think? To be honest, I spent most of the time on that part, thinking that the chances of getting this merged without discussion would improve if I just implement this instead of providing wrong values to appease killall5. Also, providing the correct values aligns our procfs more closely with the Linux one, and that is one of the points of our procfs, isn't it? What's the problem with adding support for valid values ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130829102354.ga8...@dalaran.sceen.net
Re: [PATCH 1/5] exec: remove support for transparently unbzip2ing executables
On Thu, Aug 29, 2013 at 12:52:39PM +0200, Samuel Thibault wrote: Justus Winter, le Thu 29 Aug 2013 12:41:47 +0200, a écrit : But couldn't the same be achieved by installing an unzipping storeio translator on the zipped executable? It is more explicit, but I'd argue that this is a good thing in this case and shows the flexibility of the Hurd as a whole. That better separates matters indeed. Not duplicating the deflate code is a sign of better factorization :) What do people think about it? That can mean, with nsmux, to exec, say, foo.gz,,gunzip for instance, instead of guessing. A better example would be providing an exec server for old a.out static binaries for example. But for compression, what Justus describes looks a lot more hurdish to me. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130829121524.ga27...@dalaran.sceen.net
Re: GCC internal compiler error (was: Weekly report (8th week) - Debian GNU/Hurd Debianish initialization)
On Tue, Aug 13, 2013 at 12:36:43PM +0200, Justus Winter wrote: No, it's probably not gccs fault, it might be a problem with my virtualization environment or the host system. I've seen seemingly random failures, like dpkg-query dying with SIGILL. I may be rambling about it a bit too much, but it's worth noting that darnassus (and all the sceen.net VMs) are running on a host with ECC memory. I've seen less of these issues there than on my previous environments. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130813120627.ga9...@dalaran.sceen.net
Re: [PATCH 10/16] hurd: add fsys_get_children
On Tue, Jul 30, 2013 at 12:20:32PM +0200, Neal H. Walfield wrote: fsys_get_children returns any active translators bound to nodes of the receiving filesystem as an argz vector containing file names relative to the root of the receiving translator. What if the caller is chrooted? The filenames should be relative to the caller's root. Is that really necessary ? Support for chroot has always been incomplete and present for compatibility only. In addition, Linux still shows the paths at mount time in /proc/mounts from a chroot. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130730204422.ga5...@dalaran.sceen.net
Re: [PATCH 10/16] hurd: add fsys_get_children
On Tue, Jul 30, 2013 at 10:50:51PM +0200, Neal H. Walfield wrote: I'm not concerned about the mtab implementation. I'm concerned about the RPC's interface. I'm not sure why you think chroot is only for compatibility and why we therefore shouldn't correctly support it. First, it's not POSIX. Then, its use depends on everything that requires proper file system setup to correctly work, which on the Hurd is about everything since the file system is the directory of practically all services (but even on other systems, services provided by file systems are affected). To finish with, this RPC is really intended to implement mtab, and I don't see why the current behaviour is incorrect. From my point of view, this problem raises an important design issue of the Hurd : in one mail [1], you state translators should never impersonate users, but here, it really seems necessary to make the translator temporarily inherit some of the users' properties such as its file system root. Or, if the translator merely acts as a registry and redirects users, this probably means the mtab implementation needs to be part of glibc, which seems to be an impractical way of extending system functionality ... -- Richard Braun [1] http://lists.gnu.org/archive/html/bug-hurd/2013-07/msg00214.html -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130730212439.ga11...@dalaran.sceen.net
Re: Connect through ssh
On Tue, Jul 02, 2013 at 10:25:28PM +0300, Lluís wrote: This one, I wasn't able to solve it: Jul 2 18:15:28 debian sshd[1730]: Accepted password for root from 10.0.2.2 port 34693 ssh2 Jul 2 18:15:28 debian sshd[1730]: pam_unix(sshd:session): session opened for user root by (uid=0) Jul 2 18:15:28 debian sshd[1730]: pam_ck_connector(sshd:session): cannot determine display-device Jul 2 18:15:28 debian sshd[1730]: fatal: buffer_uncompress: inflate returned -3 Jul 2 18:15:28 debian sshd[1730]: pam_unix(sshd:session): session closed for user root Increase ssh/sshd verbosity. There are two errors here, each possibly completely unrelated to the other, or not. The presence of the word fatal makes me think the second is actually the blocking one. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130702193518.ga7...@dalaran.sceen.net
Re: Connect through ssh
On Tue, Jul 02, 2013 at 11:23:15PM +0300, Lluís wrote: Dammit! Turns out ssh takes the first LogLevel line, not the last one (where I enabled debug). Here's with DEBUG3, although there's not much more relevant (to me) information: What about the client ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130702203136.ga19...@dalaran.sceen.net
Re: trouble building hurd debian package, alioth confusion
On Mon, Jun 10, 2013 at 07:30:58PM +0200, Justus Winter wrote: Quoting Richard Braun (2013-06-10 16:28:40) On Mon, Jun 10, 2013 at 04:10:57PM +0200, Justus Winter wrote: Awesome, didn't know this one. Still I was hoping to get a git repo since that way I could plug it into my package building solution. There are debian repositories for GNU Mach and the Hurd : git://anonscm.debian.org/pkg-hurd/gnumach.git git://anonscm.debian.org/pkg-hurd/hurd.git Yes, but that one is too old and... [...] You need even more recent Hurd sources. See this URL for the patch : http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=45193362a810024ab4810470fcd00e16123d5aaf ... that one lacks the packaging bits. But surely this will end up in git://anonscm.debian.org/pkg-hurd/hurd.git soonish, so I'll just wait a little. Yes, that's what happens. In the mean time, you can apply the missing bits yourself. That's why I gave you the URL of the patch concerning the last issue you're having. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130610181320.ga31...@mail.sceen.net
Re: Bogus low-memory mode
On Wed, May 29, 2013 at 11:13:30AM +0200, Richard Braun wrote: On Tue, May 28, 2013 at 08:54:00PM -0400, Donald Allen wrote: It also occurred to me to have a look at that upper memory limit that went by early as the install kernel was booting. It's 0xf6f = 258932736. No wonder the installer is complaining. Check your BIOS for any memory hole related option. Any success with that ? -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130603200334.ga1...@mail.sceen.net
Re: Bogus low-memory mode
On Tue, May 28, 2013 at 08:54:00PM -0400, Donald Allen wrote: It also occurred to me to have a look at that upper memory limit that went by early as the install kernel was booting. It's 0xf6f = 258932736. No wonder the installer is complaining. Check your BIOS for any memory hole related option. Testing on different memory sizes isn't the issue. It's testing on as many different flavors of hardware out there that claim to be PCs. This G41 was made by IBM, not Lenovo, so came from where it all started. Linux, FreeBSD, OpenBSD, and NetBSD (and maybe Dragonfly -- Yeah well, despite it's the original company, it did undergo 20 years of incremental changes with the requirement to keep old stuff for compatibility. GNU Mach actually doesn't use the BIOS E820 memory map provided by GRUB, only the E801-like lower/upper values as mentioned in the multiboot specification : The value returned for upper memory is maximally the address of the first upper memory hole minus 1 megabyte. It just happens that we didn't suffer from memory hole issues to make the effort to fix that. Also, considering GNU Mach currently only manages one contiguous block of physical memory, and some drivers (Linux drivers mostly IIRC) assume that, fixing it requires some work that may not be trivial. See gnumach/i386/i386at/model_dep.c:mem_size_init for reference. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529091330.ga1...@mail.sceen.net
Re: Bogus low-memory mode
On Wed, May 29, 2013 at 11:27:28AM +0200, Samuel Thibault wrote: Richard Braun, le Wed 29 May 2013 11:13:30 +0200, a écrit : Also, considering GNU Mach currently only manages one contiguous block of physical memory, Not really. It is already able to skip some areas as unusable, see init_alloc_aligned(). Right, this could be used for small holes. and some drivers (Linux drivers mostly IIRC) assume that Really? I've mostly seen Linux drivers use virtual memory, not physical memory. Right too, I didn't find any actually used old-style direct mem_map access. The work then reduces to parsing the E820 memory map. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130529100643.ga23...@mail.sceen.net
Re: Imminent Debian GNU/Hurd release
On Wed, May 08, 2013 at 08:31:29PM +0200, Samuel Thibault wrote: http://people.debian.org/~sthibault/tmp/README.txt Please review and send fixes. People may still use an old version of kvm where writeback isn't the default, and the performance increase is important enough to directly provide it in the qemu/kvm example. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508195923.ga17...@mail.sceen.net
Re: [HEADSUP] Upgrading to select_timeout hurdglibc packages from debian-ports
On Thu, Feb 28, 2013 at 06:24:57PM +0100, Samuel Thibault wrote: I have uploaded glibc and hurd packages with the io_select_timeout support to debian-ports. When upgrading to them, you *have* to reboot right after having upgraded the packages, because applications using select will not work until a reboot. They have been working fine so far, thanks for integrating the work. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302112354.ga12...@mail.sceen.net
Re: hurd-recommended with incubator hurdextras
On Fri, Feb 15, 2013 at 02:45:46AM +0100, Samuel Thibault wrote: I was wondering about it for some time, discussing about it etc. I ended up packaging all the incubator hurdextras small translators into a single Debian binary package, hurd-recommended, which I have uploaded to deb http://people.debian.org/~sthibault/hurd-i386/tmp ./ It seems simpler to me to gather these various useful things into a single binary package for installation, just like is done for Xorg with x11-utils etc. What do people think about it? Agreed. -- Richard Braun -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130215093945.ga31...@mail.sceen.net
