diff options
42 files changed, 2191 insertions, 296 deletions
diff --git a/.library/IkiWiki/Plugin/ymlfront.pm b/.library/IkiWiki/Plugin/ymlfront.pm index 9c033833..cbd80e32 100644 --- a/.library/IkiWiki/Plugin/ymlfront.pm +++ b/.library/IkiWiki/Plugin/ymlfront.pm @@ -20,7 +20,7 @@ our $VERSION = '1.20101116'; IkiWiki IkiWiki::Plugin::field - YAML::Any + YAML::Syck =head1 AUTHOR @@ -95,11 +95,12 @@ sub getsetup () { } sub checkconfig () { - eval q{use YAML::Any}; - eval q{use YAML} if $@; + # If installed, YAML::XS apparently is used by default -- but doesn't seem + # to work here. + eval q{use YAML::Syck}; if ($@) { - return error ("ymlfront: failed to use YAML::Any or YAML"); + return error ("ymlfront: failed to use YAML::Syck"); } $YAML::UseBlock = 1; diff --git a/.templates/editpage.tmpl b/.templates/editpage.tmpl index 1ecbd0a9..f43d7232 100644 --- a/.templates/editpage.tmpl +++ b/.templates/editpage.tmpl @@ -18,7 +18,7 @@ <TMPL_VAR FIELD-EDITCONTENT><br /> </div> <TMPL_IF NAME="CAN_COMMIT"> -<label for="editmessage" class="block">Optional comment about this change:</label> +<label for="editmessage" class="block">Optional description of this change:</label> <TMPL_VAR FIELD-EDITMESSAGE><br /> </TMPL_IF> @@ -43,21 +43,52 @@ if there are questions.</p> <TMPL_VAR HELPONFORMATTINGLINK> <TMPL_IF NAME="FIELD-ATTACHMENT"> <a class="toggle" href="#attachments">Attachments</a> +</TMPL_IF> +<TMPL_VAR FIELD-SUBSCRIBE> +<TMPL_IF NAME="FIELD-ATTACHMENT"> <div class="<TMPL_VAR ATTACHMENTS-CLASS>" id="attachments"> -<table> -<tr><td colspan="5"><TMPL_VAR FIELD-ATTACHMENT><TMPL_VAR FIELD-UPLOAD></td></tr> +<div id="fileupload"> +<script> +$(function () { $('#fileupload').fileupload(); }); // initialize upload widget +</script> +<script id="template-upload" type="text/x-jquery-tmpl"> + <tr class="template-upload{{if error}} ui-state-error{{/if}}"> + <td><input type="checkbox" name="attachment_select" value="${name}" />${name}</td> + {{if error}} + <td class="error" colspan="2">failed!</td> + {{else}} + <td class="progress" colspan="2"><div></div></td> + <td class="start"><button>Start</button></td> + {{/if}} + <td class="cancel"><button>Cancel</button></td> + </tr> +</script> +<script id="template-download" type="text/x-jquery-tmpl"> + <tr class="template-download{{if error}} ui-state-error{{/if}}"> + <td><input type="checkbox" checked name="attachment_select" value="${name}" />${name}</td> + <td>${humansize}</td> + {{if error}} + <td class="error" colspan="2">failed!</td> + {{else}} + <td>${stored_msg}</td> + {{/if}} + </tr> +</script> +<div class="fileupload-content"> +<table class="files"> <TMPL_LOOP NAME="ATTACHMENT_LIST"> -<tr><td><TMPL_VAR FIELD-SELECT><TMPL_VAR LINK></td><td><TMPL_VAR SIZE></td><td><TMPL_VAR MTIME></td></tr> +<tr><td><input type="checkbox" name="attachment_select" value="<TMPL_VAR NAME ESCAPE="HTML">" /><TMPL_VAR LINK></td><td><TMPL_VAR SIZE></td><td><TMPL_VAR MTIME></td></tr> </TMPL_LOOP> -<TMPL_IF NAME="ATTACHMENT_LIST"> -<tr><td colspan="2"><TMPL_VAR FIELD-LINK><TMPL_VAR FIELD-RENAME><TMPL_VAR FIELD-REMOVE></td></tr> -</TMPL_IF> </table> </div> +<TMPL_VAR FIELD-ATTACHMENT> +<noscript><TMPL_VAR FIELD-UPLOAD></noscript> +<TMPL_VAR FIELD-LINK><TMPL_VAR FIELD-RENAME><TMPL_VAR FIELD-REMOVE> +</div> +</div> </TMPL_IF> <TMPL_VAR FORM-END> <TMPL_VAR WMD_PREVIEW> - <TMPL_IF NAME="PAGE_PREVIEW"> <hr /> <div class="header"> diff --git a/.templates/newsitem.tmpl b/.templates/newsitem.tmpl index e8a9c861..919200bb 100644 --- a/.templates/newsitem.tmpl +++ b/.templates/newsitem.tmpl @@ -41,6 +41,12 @@ <TMPL_VAR CONTENT> <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +<TMPL_IF ENCLOSURE> +<TMPL_IF HTML5><section id="newsitemenclosure"><TMPL_ELSE><div id="newsitemenclosure"></TMPL_IF> +<a href="<TMPL_VAR ENCLOSURE>">Download</a> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +</TMPL_IF> + <TMPL_IF HTML5><footer class="newsitemfooter"><TMPL_ELSE><div class="newsitemfooter"></TMPL_IF> <!-- The saved space is more important that the information this provides. diff --git a/.templates/page.tmpl b/.templates/page.tmpl index 5192138a..44939cb5 100644 --- a/.templates/page.tmpl +++ b/.templates/page.tmpl @@ -21,12 +21,25 @@ <TMPL_ELSE> <link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" /> </TMPL_IF> + +<TMPL_UNLESS DYNAMIC> <TMPL_IF EDITURL> <link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" /> </TMPL_IF> <TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF> <TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF> <TMPL_IF META><TMPL_VAR META></TMPL_IF> +<TMPL_LOOP TRAILLOOP> +<TMPL_IF PREVPAGE> +<link rel="prev" href="<TMPL_VAR PREVURL>" title="<TMPL_VAR PREVTITLE>" /> +</TMPL_IF> +<link rel="up" href="<TMPL_VAR TRAILURL>" title="<TMPL_VAR TRAILTITLE>" /> +<TMPL_IF NEXTPAGE> +<link rel="next" href="<TMPL_VAR NEXTURL>" title="<TMPL_VAR NEXTTITLE>" /> +</TMPL_IF> +</TMPL_LOOP> +</TMPL_UNLESS> + </head> <body> @@ -47,9 +60,11 @@ </TMPL_IF> </span> </span> +<TMPL_UNLESS DYNAMIC> <TMPL_IF SEARCHFORM> <TMPL_VAR SEARCHFORM> </TMPL_IF> +</TMPL_UNLESS> <TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF> <TMPL_IF HAVE_ACTIONS> @@ -109,13 +124,19 @@ <TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> +<TMPL_UNLESS DYNAMIC> +<TMPL_VAR TRAILS> +</TMPL_UNLESS> + <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +<TMPL_UNLESS DYNAMIC> <TMPL_IF SIDEBAR> <TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF> <TMPL_VAR SIDEBAR> <TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF> </TMPL_IF> +</TMPL_UNLESS> <div id="pagebody"> @@ -123,6 +144,12 @@ <TMPL_VAR CONTENT> <TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +<TMPL_IF ENCLOSURE> +<TMPL_IF HTML5><section id="enclosure"><TMPL_ELSE><div id="enclosure"></TMPL_IF> +<a href="<TMPL_VAR ENCLOSURE>">Download</a> +<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF> +</TMPL_IF> + <TMPL_UNLESS DYNAMIC> <TMPL_IF COMMENTS> <TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF> @@ -144,6 +171,8 @@ <TMPL_UNLESS DYNAMIC> <TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF> +<TMPL_VAR TRAILS> + <TMPL_IF TAGS> <TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><div class="tags"></TMPL_IF> Tags: diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index e6f07822..5a373014 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014 Free +Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -11,24 +11,28 @@ License|/fdl]]."]]"""]] [[!meta title="Google Summer of Code"]] +<!-- The Google Summer of Code 2013 is over. Chances are that we will again be participating in 2014, stay tuned. +--> -<!-- We're in! The GNU Hurd project is again participating in the [Google Summer of Code](http://www.google-melange.com/) under the [GNU umbrella](http://www.gnu.org/software/soc-projects/). -As of Monday, 2013-04-22 it's the *student application period*. This will last -until [Friday, -2013-05-03](http://www.google-melange.com/gsoc/events/google/gsoc2013), which +Per the [Google Summer of Code 2014 Program +Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2014), on +Monday, from 2014-03-10 to 2014-03-21, it's the *student application period*, +which is plenty of time for preparing and discussing your applications -- but please don't wait to the last minute! +<!-- This year's *student application period* is over. Thanks for sending in your applications! We're now reviewing and discussing these, so please pay attention to any questions posted on your proposal's page. The Google site's notification system should be sending out emails, too. +--> As we only have finite resources (meaning that we won't be able to accept all GNU Hurd applications even if we wanted to), we will eventually need to make a @@ -37,7 +41,6 @@ with us, be it by answering the evaluators' questions on your proposal's page, or by talking to us on the [[mailing_lists]] or on [[IRC]]. At this time, it is important for us to get a good impression about the seriousness you're showing with your application. ---> If you intend to apply for any such projects in the future, it's a good idea to already start perparing for it now: the sooner, the better. @@ -47,14 +50,12 @@ send in some basic patches (as mentioned in our [[student_application_form]]), and talk to us on the [[mailing_lists]] or on [[IRC]], for example about the principal steps you're planning on doing in your intended work area. -<!-- Of course, we don't expect you to already start working seriously on your project, but any input you're giving us will make it easier for us to justify selectiong your specific proposal. At this time, it is not quantity that matters, and it also is not *the perfect patch* we're waiting for, but it is rather that we see how you're generally able to work with the code. ---> If you have any questions, don't be shy: please ask! Nobody expects you to know everything. Even for the long-term Hurd contributors it is common to @@ -73,7 +74,6 @@ discussing with our GNU peers about how to split these up among all the GNU subprojects. --> - # Possible projects We have a list of [[project_ideas]], and students are likewise encouraged to diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 39797ba0..262ead82 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -74,41 +74,58 @@ After all, the purpose of GSoC is to introduce you to free software development before the end of the application process, with our help -- contact us, and we will assist you as well as we can. -See also the list of [Hurd-related X.Org project -ideas](http://xorg.freedesktop.org/wiki/Hurd_Porting), and [Debian GNU/Hurd -Debianish -initialization](http://wiki.debian.org/SummerOfCode2013/Projects#Debian_GNU.2FHurd_Debianish_initialization). - -<!-- Olaf, wouldn't it make sense to put the following tasks next to each -other: language_bindings, gnat, gccgo, perl_python. --> - -[[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/gdb" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/xmlfs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/unionfs_boot" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/lexical_dot-dot" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/hardware_libs" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/testing_framework" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/dtrace" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]] +Here is a list of project ideas, followed by all project ideas inlined. + +[[!inline show=0 feeds=no archive=yes template="titlepage" pagenames="{{$project_ideas}}"]] + +Additional ideas have been posted in [[!message-id +"87zjkyhp5f.fsf@kepler.schwinge.homeip.net"]], but have not yet been integrated +here and elsewhere. Keywords: *bootstrap-vz*, *buildbot*, *ceph*, *clang*, +*cloud*, *continuous integration*, *debian*, *eudyptula challenge*, *gcc front +end*, *gdb*, *grub*, *guile*, *learning system*, *llvm*, *lttng*, *rump +kernels*, *samba*, *sbcl*, *smbfs*, *steel bank common lisp*, *subhurd*, +*systemtap*, *teaching system*, *tracing*, *virtio*, *x.org*, *xen*, *xorg*. +As well as any other ideas you might have, these are likewise applicable for +projects. + +All project ideas inlined: + +[[!inline show=0 feeds=no actions=yes pagenames="{{$project_ideas}}"]] + + +[[!ymlfront data=""" + +project_ideas: + + "community/gsoc/project_ideas/language_bindings + community/gsoc/project_ideas/virtualization + community/gsoc/project_ideas/file_locking + community/gsoc/project_ideas/gdb + community/gsoc/project_ideas/tcp_ip_stack + community/gsoc/project_ideas/nfs + community/gsoc/project_ideas/sound + community/gsoc/project_ideas/disk_io_performance + community/gsoc/project_ideas/vm_tuning + community/gsoc/project_ideas/gnumach_cleanup + community/gsoc/project_ideas/xmlfs + community/gsoc/project_ideas/unionfs_boot + community/gsoc/project_ideas/lexical_dot-dot + community/gsoc/project_ideas/secure_chroot + community/gsoc/project_ideas/package_manager + community/gsoc/project_ideas/download_backends + community/gsoc/project_ideas/maxpath + community/gsoc/project_ideas/gnat + community/gsoc/project_ideas/gccgo + community/gsoc/project_ideas/hardware_libs + community/gsoc/project_ideas/cdparanoia + community/gsoc/project_ideas/perl_python + community/gsoc/project_ideas/testsuites + community/gsoc/project_ideas/testing_framework + community/gsoc/project_ideas/libcap + community/gsoc/project_ideas/xattr + community/gsoc/project_ideas/valgrind + community/gsoc/project_ideas/driver_glue_code + community/gsoc/project_ideas/dtrace + community/gsoc/project_ideas/libdiskfs_locking" + +"""]] diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn index 206d4d7d..ebb322f1 100644 --- a/community/gsoc/project_ideas/file_locking.mdwn +++ b/community/gsoc/project_ideas/file_locking.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2008, 2009, 2012 Free Software Foundation, +[[!meta copyright="Copyright © 2008, 2009, 2012, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -29,6 +29,7 @@ A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]]. Possible mentors: Samuel Thibault (youpi) Exercise: Find one of the existing issues, either by looking at the task/bug +filed on [[open_issues/file_locking]], on trackers on savannah, or by trying things out yourself; and take a go at it. Note though that most of these issues are probably not trivial -- it's quite likely that you won't be able to actually fix any of them in the time available diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn index d3e17dc9..d67dbe20 100644 --- a/community/gsoc/project_ideas/object_lookups.mdwn +++ b/community/gsoc/project_ideas/object_lookups.mdwn @@ -539,3 +539,93 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]]. <teythoon> right, for dup and friends <braunr> and the radix tree is a data structure that can cope decently with not too sparsed distributions + + +## IRC, freenode, #hurd, 2014-02-27 + + <braunr> teythoon: ah, just saw the commit that will make our network + faster :) + <teythoon> network ? + <braunr> eh no, it's about ioctls actually + <braunr> :) + <braunr> i read a bit too quickly + <teythoon> one more small step towards fixing all receiver lookups in the + hurd... + <teythoon> i did not anticipate how much the hurd has to be changed first + in order to make use of the protected payloads + <braunr> that was my main reason not to do it actually :/ + <braunr> but you're almost finished with it, aren't you ? + <teythoon> not sure tbh + <teythoon> i believe the fsys stuff was the largest chunk + + +## IRC, freenode, #hurd, 2014-03-02 + + <teythoon> youpi: i cleaned up most of the receiver lookups in hurd by now + <teythoon> but there are some tricky cases left + <teythoon> 1/ the pager stuff + <teythoon> the mig declarations are in gnumach, and do not have the + necessary intran declarations that we can mutate + <teythoon> 2/ some uses of mach_port_t instead of some_type_t in the hurd + rpc definitions + <teythoon> (e.g. fsys_forward) + <teythoon> for 1/, i'd like to extend the definitions in gnumach + <teythoon> i'm not so sure what to do for the second case + <teythoon> we could introduce some types for each case + <teythoon> or, we do not touch the definitions + <teythoon> my protected payload prototype allows us to map payloads back to + port names for the functions that want a name + <teythoon> i did this by redefining the mach_port_t type for mig that uses + the payload to port-name intran function + <teythoon> mig allows type redefinitions, but emits a warning message + <teythoon> though i consider that a useful feature, it allows one to refine + a type + + +## IRC, freenode, #hurd, 2014-03-04 + + <teythoon> braunr: i fixed the object lookups in libpager yesterday, a + pretty mechanic change + <braunr> teythoon: can't be bad :) + <teythoon> amusingly, the resulting packages boot about half way through + o_O + <braunr> teythoon: ? + <teythoon> it hangs while cleaning left-over files from /tmp + <braunr> ugh, libpager .. + <teythoon> yes + <teythoon> tricky pager stuff is tricky ? + <braunr> tricky buggy pager stuff is tricky and buggy + <teythoon> ^^ + <braunr> let's assume you made things faster, increasing the likelihood of + deadlocks .. + <braunr> we had a patch once for a libpager deadlock + <teythoon> well, i'm not yet at the point where things might get faster + <braunr> see 901c61a1d25e7c8963e51012760a82730eda1910 + <braunr> the same problem exists elsewhere i think, you might have hit it + <teythoon> i'm still just moving the object lookups from the server + functions to the mig translation functions + <braunr> hm + <teythoon> but yes, i might have influenced the timing, not sure + <braunr> shouldn't cost too much to add some prints + <braunr> iirc, the other potential deadlock is in libpager/pager-attr.c + <braunr> when memory_object_change_attributes is called + <braunr> (which loops back into libpager when the kernel sends data back + <braunr> ) + <braunr> tricky .. + <teythoon> i'll try that when i get home + + <braunr> aren't you almost done ? + <teythoon> not sure tbh + <braunr> :( + <braunr> althouhg libpager would be really great + <teythoon> and mach-defpager + <braunr> since this is actually one of the biggest points of contention + <teythoon> i'll do that next, and return to libpager later + <braunr> ok + <teythoon> for both i needed to change some rpc type definitions in gnu + mach + <braunr> skipping lookups in libpager would make it harder to suffer + writeback thread storms + <teythoon> so i want to make sure that these changes are fine so that i can + propose them + <braunr> ok diff --git a/community/gsoc/project_ideas/package_manager.mdwn b/community/gsoc/project_ideas/package_manager.mdwn index d80efe37..721f6d06 100644 --- a/community/gsoc/project_ideas/package_manager.mdwn +++ b/community/gsoc/project_ideas/package_manager.mdwn @@ -1,14 +1,15 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] -[[!meta title="Hurdish Package Manager for the GNU System"]] +[[!meta title="Hurdish Package Manager for the GNU System, GNU Guix"]] Most GNU/Linux systems use pretty sophisticated package managers, to ease the management of installed software. These keep track of all installed files, and @@ -37,7 +38,7 @@ came about. There are no global databases of any kind. (Some things might require caching for better performance, but this must happen transparently.) The core of this approach is formed by [[hurd/translator/stowfs]]. -[Guix](http://www.gnu.org/software/guix), GNU's package manager, +[[GNU Guix|hurd/running/nix#guix]], GNU's package manager, installs each package in its own directory. Each user has a *profile*, which is the union of some of these packages. On GNU/Linux, this union is implemented as a symlink tree; on GNU/Hurd, @@ -46,7 +47,11 @@ Unix directory structure from all the files in the individual package directories. This handles the lowest level of package management. -The goal of this task is to exploit Hurd features in GNU Guix. +The goal of this task is to exploit Hurd features in [[GNU +Guix|hurd/running/nix#guix]]. + +See also: [Porting Guix to +GNU/Hurd](http://www.gnu.org/software/soc-projects/ideas-2014.html#guix_hurd). Possible mentors: Ludovic Courtès, Ben Asselstine (bing) diff --git a/community/gsoc/project_ideas/testsuites.mdwn b/community/gsoc/project_ideas/testsuites.mdwn index 9ca6fe3e..451c8c5f 100644 --- a/community/gsoc/project_ideas/testsuites.mdwn +++ b/community/gsoc/project_ideas/testsuites.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,7 +9,14 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Fix Compatibility Problems Exposed by Testsuites"]] +[[!meta title="Fix Compatibility Problems Exposed by Testsuites, Implement +Missing Interfaces in glibc for GNU Hurd"]] + +[[!toc]] + + +[[!if test="!included()" then="#" else="###"]] Fix Compatibility Problems Exposed by Testsuites + A number of software packages come with extensive testsuites. Some notable ones are [[open_issues/glibc]], gnulib, Perl, @@ -36,25 +44,61 @@ The goal is to analyze all failures in one or more of the listed testsuites, to find out what shortcomings in the Hurd implementation cause them (if any), and to fix at least some of these shortcomings. -Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]] listed above. +Note that this task somewhat overlaps with the [[Perl/Python task|perl_python]]. Here the focus however is not on improving the support for any particular program, but on fixing general problems in the Hurd. -This is a very flexible task: +A complementary task is adding a proper [[open_issues/unit_testing]] framework +to the GNU Hurd's code base, and related packages. + + +[[!if test="!included()" then="#" else="###"]] <a name="missing">Implement Missing Interfaces in glibc for GNU Hurd</a> + +A related project is to [implement missing interfaces for GNU +Hurd](http://www.gnu.org/software/soc-projects/ideas-2014.html#glibc_hurd_missing_interfaces) +([glibc +wiki](https://sourceware.org/glibc/wiki/GSoC#Implement_Missing_Interfaces_for_GNU_Hurd)), +primatily in [[open_issues/glibc#missing]]. + +In glibc's Linux kernel port, most simple POSIX interfaces are in fact just +forwarded to (implemented by) Linux kernel system calls. In contrast, in the +[[GNU Hurd port|/glibc]], the POSIX (and other) interfaces are actually +implemented in glibc on top of the [[Hurd RPC protocols|hurd/rpc]]. A few +examples: +[getuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/getuid.c), +[open](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/open.c), +[rmdir](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/rmdir.c), +[setresuid](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/setresuid.c), +[socketpair](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/mach/hurd/socketpair.c). + +When new interfaces are added to glibc (new editions of POSIX and similar +standards, support for new editions of C/C++ standards, new GNU-specific +extensions), generally [ENOSYS +stubs](https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/execve.c) are +added, which are then used as long as there is no real implementation, and +often these real implementations are only done for the Linux kernel port, but +not GNU Hurd. (This is because most of the contributors are primarily +interested in using glibc on Linux-based systems.) Also, there is quite a +backlog of [[missing implementations|open_issues/glibc#missing]] for GNU Hurd. + +In coordination with the [[GNU Hurd developers|mailing_lists/bug-hurd]], you'd +work on implementing such missing interfaces. + +--- + +These are very flexible tasks: while less experienced students should be able to tackle at least a few of the easier problems, other issues will be challenging even for experienced hackers. -No specific previous knowledge is required for this task; +No specific previous knowledge is required; only fairly decent C programming skills. While tracking down the various issues, the student will be digging into the inner workings of the Hurd, and thus gradually gaining the knowledge required for Hurd development in general. -A complementary task is adding a proper [[open_issues/unit_testing]] framework -to the GNU Hurd's code base, and related packages. - Possible mentors: Samuel Thibault (youpi) Exercise: Take a stab at one of the testsuite failures, +or missing implementation, and write a minimal testcase exposing the underlying problem. Actually fixing it would be a bonus of course -- but as it's hard to predict which issues will be easy and which will be tricky, diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn index 13cc6cd1..0c51bdc1 100644 --- a/community/gsoc/project_ideas/unionfs_boot.mdwn +++ b/community/gsoc/project_ideas/unionfs_boot.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!meta title="Allow Using unionfs Early at Boot"]] @@ -19,7 +20,8 @@ software packages, GNU/Linux distributions usually come with a package manager, which keeps track of all files upon installation/removal in some kind of central database. -An alternative approach is the one implemented by GNU Stow and GNU Guix: each package is +An alternative approach is the one implemented by [[GNU Stow and GNU +Guix|package_manager]]: each package is actually installed in a private directory tree. The actual standard directory structure is then created by collecting the individual files from all the packages, and presenting them in the common `/bin`, `/lib`, etc. locations. diff --git a/contributing.mdwn b/contributing.mdwn index 08c11041..485bdd47 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -97,7 +97,8 @@ part:1:file:/home/samy/tmp/foo`). This would be libnetfs-based. [[GSoC proposal|community/gsoc/project_ideas/valgrind ]] about this, but the basic port could be small. * Add `/proc/$pid/maps`. `vminfo` already has this kind of information, it's a matter of making procfs do the same. [[!GNU_Savannah_bug 32770]] -* Move the mount/umount logic from `utils/{,u}mount.c` into [[hurd/libshouldbeinlibc]]. +* Move the [[mount/umount|open_issues/glibc#mount]] logic from +`utils/{,u}mount.c` into [[glibc]]. * Fix [[`/proc/self`|hurd/translator/procfs/jkoenig/discussion#self]]. Look at `[glibc]/hurd/lookup-retry.c` for how [`FS_RETRY_MAGICAL` lookups|hurd/interface/dir_lookup]] work. diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 95c23920..97af245c 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -29,3 +29,35 @@ Just in case you were wondering: the *root* password is empty. [[!if test="destpage(hurd/running/qemu)" then="" else="For more detailed instructions, please see the [[hurd/running/QEMU]] page."]] + + +[[!if test="!included()" then="#" else="###"]] IRC, freenode, #hurd, 2014-03-10 + + <mcsim> scp doesn't work either + <braunr> what ? + <braunr> why wouldn't it ? + <mcsim> scp -P5555 -r ./hurd/ root@localhost:/root/src/ + <mcsim> root@localhost's password: + <mcsim> The Hurd is not Linux. Make sure to read + <braunr> that shouldn't happen ... + <braunr> use tar maybe ? + <mcsim> the same with tar archive + <braunr> :/ + <braunr> i don't know what to tell you + <braunr> i don't have that problem + + +[[!if test="!included()" then="##" else="####"]] IRC, freenode, #hurd, 2014-03-11 + + <teythoon> braunr: mcsims scp problem is b/c youpis images echo stuff from + the .bashrc or something + <teythoon> i wish he'd change that, as it is a reoccuring problem + <teythoon> youpi: ^ + <teythoon> (didn't realize you are around >,<) + <teythoon> now that /etc/issue is displayed, you can put the welcome text + there + <braunr> teythoon: i see + <teythoon> mcsim: your ssh trouble are rooted in the .bashrc printing some + stuff to stdout + <mcsim> teythoon: thank you. It works now + <teythoon> :) diff --git a/hurd/running/nix.mdwn b/hurd/running/nix.mdwn index 332fc03b..68052948 100644 --- a/hurd/running/nix.mdwn +++ b/hurd/running/nix.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,7 +9,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!meta title="Nix-based GNU/Hurd System"]] +[[!meta title="Nix-based GNU/Hurd System, Guix"]] + +[[!toc]] + + +# Nix <http://www.nixos.org/> @@ -25,7 +31,7 @@ Nix, and because of that, it uses per-package installation directories under `/nix/store`. -# IRC, freenode, #hurd, 2013-02-04 +## IRC, freenode, #hurd, 2013-02-04 <braunr> is it possible to use nix ? <braunr> or nixos @@ -39,3 +45,468 @@ Nix, and because of that, it uses per-package installation directories under <civodul> (my favorite) <civodul> i've been willing to unbreak it, but now i rather invest time in Guix + + +# <a href="guix">Guix</a> + +## <http://www.gnu.org/software/guix/> + +## IRC, freenode, #hurd, 2014-02-13 + + <phant0mas> is debian hurd the only way to use hurd? + <braunr> maybe + <braunr> there is arch hurd but i haven't heard from them in some time + <braunr> building from source is difficult + <phant0mas> what is the problem with building from source? + <braunr> no automated build system, except for debian + <braunr> each project has its own build system + <braunr> but there is no tool to take care of the global procedure + (i.e. build in the correct order, with the correct options, paths and + patches, etc...) + <youpi> well, there is, it's called Debian :) + <braunr> 00:17 < braunr> no automated build system, except for debian + <phant0mas> how far away is it from building a gnu system with let's say + guix as a package manager? + <phant0mas> and hurd as the kernel? + <braunr> i don't know + <youpi> phant0mas: there are already proofs of concepts + <phant0mas> youpi: any more info about the proofs of concepts? + <youpi> phant0mas: ask civodul + <youpi> apparently he's not here atm, though + <phant0mas> I will ask him at guix channel + + +## IRC, freenode, #hurd, 2014-02-14 + + <phant0mas> can I ask a question about configuring gnu mach from source? + <taylanub> phant0mas: IRC etiquette: don't ask to ask, just ask, it saves + time. People often leave IRC open for long durations but don't always + check it, if you just leave your question in the channel someone might + come back and see it at any time (even hours later). + <phant0mas> when I try to configure gnumach with + <phant0mas> CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld + -melf_i386' ./configure --prefix= --host=i686-unknown-linux-gnu + <phant0mas> on a 64 bit system + <phant0mas> I get the error + <phant0mas> checking for i686-unknown-linux-gnu-gcc... gcc -m32 + <phant0mas> checking whether the C compiler works... no + <phant0mas> configure: error: in `/home/manolis/Downloads/gnumach-1.4': + <phant0mas> configure: error: C compiler cannot create executables + <phant0mas> but if I remove the -m32 from CC='gcc -m32' the error + disappears + <phant0mas> what is the problem? + <braunr> what do you think there is a problem ? + <braunr> i don't think -m32 should be part of CPP/CC, but rather CPPFLAGS + <braunr> also, i don't think you need it since the target is well defined + <phant0mas> I am following exaclty the instruction from here + http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html + <braunr> hm that's weird + <braunr> phant0mas: what does gcc -v says and what's your host system ? + <phant0mas> Using built-in specs. + <phant0mas> COLLECT_GCC=gcc + <phant0mas> + COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper + <phant0mas> Target: x86_64-unknown-linux-gnu + <phant0mas> Configured with: /build/gcc/src/gcc-4.8-20131219/configure + --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib + --mandir=/usr/share/man --infodir=/usr/share/info + --with-bugurl=https://bugs.archlinux.org/ + --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared + --enable-threads=posix --with-system-zlib --enable-__cxa_atexit + --disable-libunwind-exceptions --enable-clocale=gnu + --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique- + <phant0mas> object --enable-linker-build-id --enable-cloog-backend=isl + --disable-cloog-version-check --enable-lto --enable-plugin + --enable-install-libiberty --with-linker-hash-style=gnu + --disable-multilib --disable-werror --enable-checking=release + <phant0mas> Thread model: posix + <phant0mas> gcc version 4.8.2 20131219 (prerelease) (GCC) + <braunr> check config.log for the actual error message then + <phant0mas> http://pastebin.com/raw.php?i=eQ75qafX + <phant0mas> if you want to have a look as well + <braunr> install gcc-multilib maybe + <braunr> or lib32gcc1 + <sjbalaji> Installing gcc-multilib solves it. + <phant0mas> braunr: it works like a charm now + <braunr> phant0mas: good + + +## IRC, freenode, #hurd, 2014-02-18 + + <phant0mas> why mig has no make target, and the executable gets generated + from the ./configure? + <phant0mas> I mean shouldn't make be the one building mig? + + +## IRC, freenode, #hurd, 2014-02-19 + + <phant0mas> mig binary shouldn't be built by make? why is it built at the + end of the configure command? + <braunr> no idea + <phant0mas> http://pastebin.com/raw.php?i=2HVni53Y + <braunr> "creating mig" you mean ? + <phant0mas> loot at the end of the config output + <phant0mas> config.status: creating mig <-- + <phant0mas> the binary + <phant0mas> and then when you call make + <phant0mas> it says no target + <braunr> weird + <phant0mas> normally binaries are built from make + <braunr> what system are you building on ? + <phant0mas> on Arch Linux x86_64 with gcc version 4.8.2 + <phant0mas> I am using the flag i686-pc-gnu to crossbuild it for 32 bit + <phant0mas> I am using the tar file from here + http://ftp.gnu.org.ua/gnu/mig/ + <phant0mas> version 1.4 + <braunr> tar file ? + <braunr> ok, i guess it's fine + <phant0mas> so source from the tar file builds mig through configure? + <braunr> again, i don't know + <braunr> i never build mig myself + <braunr> but it does look weird + <braunr> look at the debian package maybe + <braunr> who knows, maybe you'll find a patch with some explanation + <phant0mas> okay then,going over that way right away + <phant0mas> thnx braunr + <teythoon> phant0mas: mig is a shell script wrapper + <phant0mas> so it's not a binary.... + <teythoon> no + + +## IRC, freenode, #hurd, 2014-02-21 + + <phant0mas> do I need some minimal set of drivers to build gnumach? + <phant0mas> because I get this error + ../linux/src/drivers/scsi/BusLogic.c:53:24: fatal error: FlashPoint.c: No + such file or directory + <phant0mas> when running make + <teythoon> i thought we fixed that + <teythoon> are your sources up to date ? + <phant0mas> I am using the tar ball + <phant0mas> cause I am trying to package it for guix + <teythoon> what tarball ? + <braunr> 1.4 + <phant0mas> yes + <braunr> phant0mas: just don't build scsi drivers + <phant0mas> 1.4 + <phant0mas> worked + <teythoon> why do we keep the driver if it doesn't even build ? + <gg0> on debian it builds with --disable-net-group --disable-pcmcia-group + --disable-wireless-group + + +## IRC, freenode, #hurd, 2014-02-23 + + <phant0mas> why when I configure gnumach like this CPP='gcc -m32 -E -x c + -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ./configure --prefix= + --host=i686-unknown-linux-gnu it builds just fine but when I try to + configure it with ./configure --prefix= --host=i686-unknown-linux-gnu + CFLAGS='-m32' CPPFLAGS='-m32 -E -x c -undef -ansi' LDFLAGS='-melf_i386' + <phant0mas> I am building it on a 64 bit machine + <phant0mas> when setting env vars before configuring everythings works like + a charm + <phant0mas> but if I pass them as flags to the configure ,it won't + + +## IRC, freenode, #hurd, 2014-02-25 + + <phant0mas> what version of mae do I need in order to compile glibc for + hurd? + <phant0mas> make* + <azeem> phant0mas: did you have issues with a particular version? + <azeem> I believe GNU make is required, though + <phant0mas> I am using gnu make 4.0 and I get the error + <phant0mas> These critical programs are missing or too old: make + <phant0mas> checking version of gmake... 4.0, bad + <azeem> phant0mas: that sounds bogus + <azeem> can you pastebin the relevant part of the config.log or so? + <phant0mas> of course one sec + <phant0mas> http://pastebin.com/raw.php?i=4CHZJi4W + <phant0mas> azeem_: any news about the problem I have with glibc? + <azeem_> phant0mas: sorry - got distracted - I suggest you post this to + bug-hurd or so + <azeem_> though it could well be Hurd-independent, then checking glibc + master and possibly filing a report there might be better + <azeem_> phant0mas: or in case you speak autoconf, check the conf check for + the make version + + +## IRC, freenode, #hurd, 2014-02-26 + + <tschwinge> ph4nt0mas: Which glibc sources, and how are you + configuring/building? + <phant0mas> tschwinge: I am trying to crossbuild it from a linux 64 bit + machine with gnu make 4.0 and gcc 4.8.2 + <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/ + --target=i686-pc-gnu + <phant0mas> wrong config + <phant0mas> ../configure --prefix=/home/manolis/gnu/glibc/ + --with-headers=/home/manolis/gnu/include/ --host=i686-pc-gnu + <phant0mas> I am using the last one + <phant0mas> it says gnu make is too old + <phant0mas> this time I tried with glibc from the hurd git repo + <phant0mas> baseline branch + <phant0mas> should I build an older toolchain just for it? + <tschwinge> phant0mas: If you'd like to experiment with this, then please + use the tschwinge/Roger_Whittaker branch. However, that one might still + be missing the glibc upstream change to allow GNU Make 4.0 and greater, + commit 28d708c44bc47b56f6551ff285f78edcf61c208a, so cherry-pick that one + (assuming there are no additional patches needed for GNU Make 4.0). + <phant0mas> okay going to do that right away + <phant0mas> thnx :-) + <tschwinge> phant0mas: You have seen + http://www.gnu.org/software/hurd/toolchain/cross-gnu.html -- but beware + this may be out of date somewhat. + <phant0mas> tschwinge: I worked around that problem as you told me + <phant0mas> but it seems I forgot to build hurd + <phant0mas> so I got the tarball + <phant0mas> but I am getting this error + <phant0mas> No rule to make target 'lowlevellock.h', needed by 'timefmt.o'. + Stop. + <phant0mas> after I manage to make all of this work I will write an up to + date guide on how to build the hurd system + <phant0mas> for future reference + + +## IRC, freenode, #hurd, 2014-02-27 + + <ph4n70m4s> when trying to build gnumach microkernelin a 32 bit enviroment + it builds just fine + <ph4n70m4s> but when i try to crossbuild it from a 64 bit machine, even + though i am using --target=i686-gnu --host=i686-gnu to crossbuild it I + am just getting the error i386/i386/i386asm.symc:116:1: warning: asm + operand 0 probably doesn't match constraints [enabled by default] + <ph4n70m4s> __asm ("\n\ + <ph4n70m4s> ^ + <ph4n70m4s> i386/i386/i386asm.symc:116:1: error: impossible constraint in + 'asm' + <ph4n70m4s> http://pastebin.com/raw.php?i=emag63N4 + <ph4n70m4s> the config.log + <ph4n70m4s> and the build output if anyone want to have a look + <ph4n70m4s> http://pastebin.com/raw.php?i=jAZPnybB + <ph4n70m4s> wants* + <ph4n70m4s> I am building through guix so you may see some strange paths + <tschwinge> ph4n70m4s: Nice, Guix! :-) + <tschwinge> ph4n70m4s: Does that help? CC=gcc\ -m32 + <tschwinge> Because: + <tschwinge> configure:3574: gcc -v >&5 + <tschwinge> Using built-in specs. + <tschwinge> COLLECT_GCC=gcc + <tschwinge> + COLLECT_LTO_WRAPPER=/nix/store/7awbhk5hdkd4lqj4wsj6lm6h84630jhm-gcc-4.8.2/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper + <tschwinge> Target: x86_64-unknown-linux-gnu + <teythoon> guix looks nice + <tschwinge> ph4n70m4s: Also you don't need --target with GNU Mach -- it + doesn'T target any architecture, that is, doesn'T create code or similar. + <tschwinge> Alternative to -m32, as you're specying --host=i686-gnu, you + could have (that is, you'd need) a i686-gnu-gcc (that internally defaults + to -m32 then). + <tschwinge> ph4n70m4s: Are you generally working on GNU Hurd support for + Guix, or just trying to build GNU Mach? + <ph4n70m4s> I am working on porting gnu guix to gnu hurd + <ph4n70m4s> so I need to port hurd to it + <ph4n70m4s> bootstrap it + <ph4n70m4s> and the make guix work on hurd + <ph4n70m4s> :-) + <teythoon> very cool :) + <tschwinge> \o/ + <ph4n70m4s> then* + <ph4n70m4s> and If I manage to do all that we will be able to make a qemu + image + <ph4n70m4s> with hurd -guix + <tschwinge> Yep, and then I'll be happy. :-) + <ph4n70m4s> :-) + <tschwinge> For then we'll be easily able to change some detail in, say, + glibc, rebuild the whole system, and see whether it still works. + <ph4n70m4s> exaclty + <tschwinge> Of course, that doesn't strictly need Guix, but it's one way to + achieve this goal. + <tschwinge> For the initial cross compiler toolchain, I suggest you look at + my cross-gnu script (link provided yesterady) -- the gist of it should + all still be valid. + <ph4n70m4s> I do + <tschwinge> For example, you don't actually need to build GNU Mach + initially, but just need to install the headers/defs files + (install-data). + <tschwinge> Perfect. + <ph4n70m4s> I have already done that, installing gnu mach headers was the + easy part + <ph4n70m4s> it's already on guix + <tschwinge> \o/ + <tschwinge> Should really clone Git repository. And subscribe to the + mailing list, and all that. + <ph4n70m4s> I have already done that + <ph4n70m4s> I am actually following hurd from last year + <tschwinge> Yeah, I was talking about me. ;-) + <ph4n70m4s> aaaa + <ph4n70m4s> :P + <tschwinge> ph4n70m4s: Are you doing this as a Google Summer of Code + project? + <ph4n70m4s> I suggested the idea for the page + <ph4n70m4s> to ludovic + <ph4n70m4s> and he agreed + <tschwinge> :-) + <tschwinge> Good guy. + <tschwinge> Both of you. ;-) + <ph4n70m4s> trying my best to help :-) + <ph4n70m4s> tschwinge: so to build glibc I only need mach and hurd headers + <ph4n70m4s> right? + <braunr> yes + + +## IRC, freenode, #hurd, 2014-02-28 + + <phant0mas> tschwinge: In your cross-gnu script while configuring hurd you + pass--disable-profile + <phant0mas> --without-parted . Why do we need to pass these flags to it? + <teythoon> well, --disable-profile turns off profiling afaiui + <teythoon> you should keep it + <teythoon> --without-parted is not needed if you have libparted + <phant0mas> ok + + +## IRC, freenode, #hurd, 2014-03-01 + + <phant0mas> The hurd tarball has as a dependency autoconf + <phant0mas> normally it shouldn't, right? + <azeem> phant0mas: you mean there's no configure script? + <phant0mas> no no, for some reason the configure script states as + dependency autoconf which it shouldn't as it is a tarball + <azeem> phant0mas: how does it state that? + <phant0mas> you already have the configure script in it + <azeem> you get an error running it saying autoconf is required? + <phant0mas> yes + <azeem> hrm + <phant0mas> actually it gives an error for autoconf and git + <phant0mas> but if you have autoconf ,it forgets about git + + +## IRC, freenode, #hurd, 2014-03-02 + + <phant0mas> youpi: civodul told me you are the one to ask about libpthread + <phant0mas> how should I handle Hurd's libpthread in order to build it,with + the rest of the hurd system? + <phant0mas> anything I should be extra carefull? + <phant0mas> I am building it from the tarball + <youpi> phant0mas: nothing I can think of + + +## IRC, freenode, #hurd, 2014-03-03 + + <phant0mas> youpi: what does libpthread do when we do "make + install-data-local-headers" ? + <phant0mas> Does it patch the mach headers in the prefix folder? + <phant0mas> tschwinge: why do we need this flag passed to configure at + libpthread "ac_cv_lib_ihash_hurd_ihash_create"? + <youpi> phant0mas: I don't remember such detajils of the build system + <phant0mas> I am studying the cross-gnu script from tschwinge + <phant0mas> and if I try to call configure without that flag I am getting + the error + <phant0mas> configure: error: need libihash + <tschwinge> Well, there's this comment: # `$TARGET-gcc' doesn't work yet + (to satisfy the Autoconf checks), but [...] + <tschwinge> At this point we're only intested in the header files, so that + was the "path of least resistance". + <phant0mas> so we are only interested in the headers of libpthread? + <phant0mas> do I need to pass as --prefix the folder which the include + folder with the mach headers are installed? + <tschwinge> I wonder whether it'd be better for you to directly include + libpthread in glibc, as Debian is doing -- probably yes. + +[[open_issues/packaging_libpthread]]. + + <phant0mas> maybe it would be much simpler that way + <phant0mas> let me check the debian package + <braunr> i'd consider it mandatory, since libpthread can't work correctly + now if it's not part of glibc + <tschwinge> Ack. + + +## IRC, freenode, #hurd, 2014-03-05 + + <teythoon> braunr: did i understand it correctly that our libpthread needs + libihash ? + <teythoon> if so, won't that be a problem for phant0mas bootstrapping + efforts ? + <braunr> apparently, they're used only for thread-specific data + <braunr> which could now be implemented on top of TLS + <braunr> although i'm not sure + <braunr> but to answer, yes, it depends on libihash + <braunr> why would it be a problem ? + <teythoon> b/c it then forms a dependency loop + <braunr> which one ? + <teythoon> hurd->libc (which includes libpthread, thus)->hurd + <braunr> isn't that already the case ? + <teythoon> yes + <braunr> what's the problem then ? + <braunr> actually, it's not a dependency loop + <teythoon> y not ? + <braunr> hurd and libc depend on each other headers + <teythoon> ah, right + <braunr> actually, hurd-libs depend on libc headers + <braunr> hurd executables do depend on libc + <braunr> it's a bit tedious to bootstrap but not much more than the + three-step build required for linux already + <phant0mas> actually for that libihash if I pass the flag + "ac_cv_lib_ihash_hurd_ihash_create=yes" at configure it stops asking for + it + + <phant0mas> when glibc's configure says "configure: running configure + fragment for add-on libpthread" + <phant0mas> does it mean it runs configure inside the folder of libpthread? + <youpi> I guess so + <phant0mas> yeh because I am getting the error configure: error: cannot + find sources (include/pthread/pthread.h) in .. or .. + <phant0mas> which I should not as I am passing + <phant0mas> the path to that folder + <phant0mas> it's an error from libpthread configure + + +## IRC, freenode, #glibc, 2014-03-05 + + <phant0mas> when we pass to the configure script of glibc the flag + --enable-add-ons=something what it the process followed for that addon? + How does it build it? + <phant0mas> what is* + + +## IRC, freenode, #hurd, 2014-03-05 + + <phant0mas> ../configure --without-cvs --build=i686-pc-gnu + --host=i686-pc-gnu --target=i686-pc-gnu --prefix="/home/manolis/gnu/" + --with-headers="/home/manolis/gnu/include/" --disable-profile + --disable-multi-arch --enable-add-ons=libpthread + <phant0mas> trying to configuring glibc with libpthreads as addon I get + this + <phant0mas> configure: running configure fragment for add-on libpthread + <phant0mas> configure: WARNING: you should use --build, --host, --target + <phant0mas> configure: WARNING: you should use --build, --host, --target + <phant0mas> configure: error: cannot find sources + (include/pthread/pthread.h) in .. or .. + <phant0mas> without libpthread it moves on + <phant0mas> in the include folder it should find al the headers it needs + <phant0mas> maybe it's a problem that I installed the headers from the + tarballs + <phant0mas> while glibc is from the git repo + <phant0mas> if I remove libpthread + <phant0mas> I get the error configure: error: Hurd headers not installed or + too old + <phant0mas> I really think I should reinstall the headers using the source + from the repo the headers + <phant0mas> the headers from the tar ball are okay + <phant0mas> when I pass this flag to "--enable-add-ons=libpthread" to glibc + configure how can I pass flags for the libpthread configure that it's + called while configuring? + <teythoon> phant0mas: you could look at what the debian package does + <phant0mas> ok + <braunr> phant0mas: check debian glibc for all the patches + + +## IRC, freenode, #hurd, 2014-03-10 + + <ph4n70m4s> tschwinge: While crosscompiling glibc I get the error "Error: + incorrect register `%rax' used with `l' suffix" + <ph4n70m4s> http://pastebin.com/raw.php?i=ZJKHrm4s + <ph4n70m4s> Any idea why is this happening? + <braunr> ph4n70m4s: something is trying to compile as an x86-64 object, + while the hurd is i386 only diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 2fe43e05..5a13a655 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -368,24 +368,41 @@ Once you have logged in as `root` run the `pfinet` translator with values that a That should do it! Do not forget to edit/update `/etc/resolv.conf` to get DNS working. -# QEMU Multiboot +# <a name="multiboot">Multiboot</a> -See [[open_issues/debugging_gnumach_startup_qemu_gdb/#index2h1]]. See "Linux/Multiboot boot specific" section on QEMU manpage. -Get for instance cdimage boot components +Get the multiboot modules. Either extract them from the disk image, or, +download: - $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/{gnumach.gz,initrd.gz,ext2fs.static,ld.so.1} + $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/{gnumach.gz,ext2fs.static,ld.so.1} -gnumach needs to be uncompressed +Generally, these files need to correspond to the ones in the disk image, so +don't forget to keep them up to date. + +The kernel image needs to be uncompressed (`gunzip gnumach.gz`), as otherwise +you'll get told: *qemu: linux kernel too old to load a ram disk*. + + $ qemu [...] \ + > --kernel gnumach \ + > --initrd \ + > '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 device:hd0s1 $(task-create) $(task-resume)',\ + > 'ld.so.1 /hurd/exec $(exec-task=task-create)' + +Note that, contrary to [[GRUB]]'s configuration file, you don't specify +"`argv[0]`" here, and it's fortunate that neither ext2fs nor exec need a comma +on their command line... + +You can also use `--append [...]`, which will show up in `/proc/cmdline`. + + +# `qemu: fatal: Trying to execute code outside RAM or ROM at 0x000000010010001e` + +This is due to a bug in QEMU, where the x86_64 QEMU binary fails to properly +truncate addresses in 32-bit mode. Waiting for [[!message-id +"1386334344-24620-1-git-send-email-agraf@suse.de"]] to be applied and become +generally available, just use the `qemu-system-i386` binary instead. - $ gunzip gnumach.gz - $ sudo qemu-kvm \ - --kernel gnumach \ - --initrd " \ - initrd.gz \$(ramdisk-create), \ - 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), \ - ld.so.1 /hurd/exec \$(exec-task=task-create)" # Related Links diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index ba849cca..81e54dff 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -431,6 +431,41 @@ That would be a nice improvement, but only after writeback throttling is impleme <gnu_srs1> k, the file created with mke2fs has 128 +### IRC, freenode, #hurd, 2014-03-10 + + <mcsim> hi. I'm having problems with copying directory from host machine to + hurd image. I mount hurd image at host and than use "cp -r" to copy + directory. Then I unmount image and start qemu. When I try to see + contents of the directory I get error "Computer bought the farm". + <braunr> mcsim: are you using the ext4 driver from linux ? + <mcsim> I use image debian-hurd-20140211.img from + <braunr> if so, avoid it + <mcsim> ok + <mcsim> i'll try + <mcsim> braunr: do I have to compile module on my own? because modprobe + ext2 && lsmod | grep ext2 give no output? + <braunr> maybe + <braunr> mcsim: what kernel are you using ? + <mcsim> 3.12 + <braunr> oh + <mcsim> braunr: what is wrong with it? + <braunr> grep 'EXT[234]' /boot/config* + <braunr> it probably uses ext4 for ext2 and ext3 + <braunr> and i don't think it's possible to simply load the ext2fs module + <braunr> because the options are mutually exclusive iirc + <mcsim> # CONFIG_EXT2_FS is not set + <mcsim> is there another way to copy data? + <braunr> probably not + <braunr> (check for CONFIG_EXT4_USE_FOR_EXT23) + <gg0> mcsim: install 3.10 + http://snapshot.debian.org/package/linux/3.10.11-1/#linux-image-3.10-3-686-pae_3.10.11-1 + <gg0> https://bugs.debian.org/738758 + <gg0> assuming host is debian + <mcsim> gg0: thank you + * gg0 redirects thanks to AliciaC who caught it + <AliciaC> gg0: thanks :) + + ## `ext2fs: ../../ext2fs/pager.c:401: file_pager_write_page: Assertion 'block' failed.` ### IRC, freenode, #hurd, 2014-02-19 diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index 89593436..c3c43f43 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -3046,3 +3046,141 @@ Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? <braunr> teythoon: ok <braunr> teythoon: i let you fix that :p <teythoon> braunr: sure ;) + + +## <a name="chroot">`chroot`</a> + +### IRC, OFTC, #debian-hurd, 2014-03-05 + +In context of [[open_issues/nightly_builds_deb_packages]]. + + <gg0> installer gets stuck running os-prober, seems because + /target/proc/mounts gets unreadable, sometimes Resource lost sometimes it + gets stuck reading it + <gg0> there are two proc translators: one /proc, one /target/proc + <gg0> anything known that could have broken /target one? + <gg0> anything else to check? + <gg0> what's unusual is that cat'ing /proc takes few seconds before giving + output. does initrd slow down things? + <gg0> */proc/mounts + <gg0> what does "Resource lost" mean? i get it since the beginning of + install + + +### IRC, freenode, #hurd, 2014-03-05 + + <gg0> debian installer mounts installation disk under /target then probably + it debootstraps on it + <gg0> we have 2 procfs: one outside, one inside /target + <gg0> outside it works fine, inside cat'ing /proc/mounts it gives Resource + lost the first time. the second one it gets stuck + <gg0> oh there's only one /hurd/mtab though. inside one might have bought + the farm, correct? + <braunr> ? + <gg0> two /proc/mounts means you have to have two mtab translators afaiu + <gg0> i can't reproduce on a clean chroot + <teythoon> gg0: two mtab instances should be fine + <teythoon> also, the one under /target should only list translators "under + <teythoon> "under" /target + <gg0> teythoon: yeah i restart the dead one but at first access i get + "Resource lost" again and mtab dies + <teythoon> hm + <gg0> wait + <gg0> "Resource lost" means mtab is not running + <teythoon> are you sure ? + <teythoon> the mtab translator queries other translators + <teythoon> that can lead to the delay you described + <teythoon> and severe enough errors are handed back to the client, e.g. if + mtab itself gets resource lost on the very first translator it queries + <gg0> i'd like to clean up chroot proc and mtab stuff but settrans -fg gets + stuck + <gg0> or it gives + <gg0> settrans: /proc/mounts: Computer bought the farm + <gg0> settrans: /proc/mounts: Operation not supported + <teythoon> gg0: try settrans --recursive ... + <teythoon> then again, i never used this and it should work without, no ? + <gg0> same behavior + <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + <gg0> settrans: sid-chroot/proc/mounts: Computer bought the farm + <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + <gg0> settrans: sid-chroot/proc/mounts: Operation not supported + <gg0> root@hurd01:~# settrans --recursive -fg sid-chroot/proc/mounts + <teythoon> hm + <gg0> (last got stuck) + <teythoon> eh, i thought of settrans --recursive -fg sid-chroot + <gg0> i doesn't work. it gives no output but showtrans shows translators + didn't go away + <teythoon> showtrans shows passive translator records + <gg0> ah + <teythoon> better use fsysopts to query the active one + <gg0> both still active, even with fsysopts + <teythoon> hm + <teythoon> i recently improved the mtab translator, but that change has not + made its way into debian yet + * gg0 adding hurd-ci + +[[open_issues/nightly_builds_deb_packages]]. + + <gg0> btw Resource lost/mtab dying i can't reproduce on hurd01 seems + breaking debian installer + <gg0> teythoon: dist-upgraded hurd-ci, it behaves pretty same way besides + settrans -fg sid-chroot/proc/mounts gives "Operation not supported" right + away, without "Computer..farm" first + <gg0> following attempts it simply gets stuck + <braunr> time to quickdraw gdb :p + <gg0> teythoon: i think easy to reproduce, just need to debootstrap + <gg0> anything stronger than -fg? + <teythoon> kill + <gg0> well mtab has been already manually killed + <gg0> i could kill procfs too + <teythoon> yes, but then it seems to me that the translator linking in + netfs is buggy + <braunr> kill -KILL :p + <teythoon> :D + <teythoon> aka double kill + <gg0> ok by killing chroot procfs then accessing sid-chroot/proc/mounts + makes both restarting + <teythoon> ok, even more likely to be a netfs issue then + <teythoon> which is to be expected + <teythoon> afaik procfs is the first netfs based translator to support + passive translator records + <braunr> it is + <gg0> did the same on debian installer machine: both restarted, cat + /target/proc/mounts -> Resource lost + <gg0> and mtab died + <gg0> Computer wanted to buy the farm but it was out of resources + + +### IRC, OFTC, #debian-hurd, 2014-03-05 + + <gg0> btw problem is cat /target/proc/mounts gives Resource lost, what + package could cause that? + <gg0> and mtab dies + <youpi> Resource lost often means the same as Computer bought the farm: + some translator has died somehow + <youpi> or dropped something + <gg0> procfs+mtab outside /target work well. inside mtab crashes + <gg0> http://postimg.org/image/vgz541z81/ + <gg0> tbh i unmounted a couple, they are not all fs mounted by install, a + couple missing + <gg0> could any of them cause mtab crash? + <youpi> see ldd /hurd/mtab + <youpi> it only uses hurd libraries and pthread + <gg0> hurd libs and pthread _outside_ chroot, right? + <youpi> in principle it's the outside /hurd/mtab which gets triggered + <youpi> since the /target ext2fs doesn't know people use it chrooted + <youpi> do you have two processes? + <youpi> (mtab processes I mean) + <gg0> yes two mtabs children of their two procfs + <youpi> k + <youpi> and does setting up an mtab translator by hand gets the same? + <gg0> to restart mtab i have to kill its father procfs + <youpi> tell that to teythoon, not me, he implemented the thing :) + <gg0> then first access to /proc/mounts should make procfs and mtab restart + <gg0> yeah there's already been some troubleshooting on #hurd + <teythoon> youpi: i suspect some bugs in netfs translator linking + <teythoon> procfs is the first netfs based translator to make use of + passive translators + <gg0> you can see dead mtab and os-prober trying to grep /proc/mounts + http://postimg.org/image/z4fm981p7/ + <gg0> well, there can't be problems on /target if there's not /target yet diff --git a/ikiwiki.setup b/ikiwiki.setup index b07c582c..cfb3e646 100644 --- a/ikiwiki.setup +++ b/ikiwiki.setup @@ -19,10 +19,10 @@ my $gitorigin_branch = ''; if (defined $ENV{WEB_SERVER}) { - $srcdir = $root.'/hurd-web'; + $srcdir = $root.'/public_html.workspace'; $destdir = $root.'/public_html'; - $cgi_wrapper = $root.'/hurd-web.cgi'; - $git_wrapper = $root.'/hurd-web.update'; + $cgi_wrapper = $root.'/public_html.workspace.cgi'; + $git_wrapper = $root.'/public_html.workspace.update'; $gitorigin_branch = 'origin'; } else @@ -56,6 +56,12 @@ IkiWiki::Setup::Standard->import({ cgi_wrapper => $cgi_wrapper, # mode for cgi_wrapper (can safely be made suid) cgi_wrappermode => '06755', + # number of seconds to delay CGI requests when overloaded + #cgi_overload_delay => '', + # message to display when overloaded (may contain html) + #cgi_overload_message => '', + # enable optimization of only refreshing committed changes? + #only_committed_changes => 0, # rcs backend to use rcs => 'git', # plugins to add to the default configuration @@ -84,7 +90,7 @@ IkiWiki::Setup::Standard->import({ discussion => 1, # name of Discussion pages discussionpage => 'Discussion', - # generate HTML5? (experimental) + # generate HTML5? html5 => 0, # only send cookies over SSL connections? sslcookie => 0, @@ -102,14 +108,16 @@ IkiWiki::Setup::Standard->import({ numbacklinks => 10, # attempt to hardlink source files? (optimisation for large files) hardlink => 1, - # force ikiwiki to use a particular umask - #umask => 022, + # force ikiwiki to use a particular umask (keywords public, group or private, or a number) + #umask => 'public', # group for wrappers to run in #wrappergroup => 'ikiwiki', # extra library and plugin directory libdir => $srcdir.'/.library', # environment variables ENV => {}, + # time zone name + #timezone => 'Europe/Berlin', # regexp of normally excluded files to include #include => '^\\.htaccess$', # regexp of files that should be skipped @@ -118,6 +126,12 @@ IkiWiki::Setup::Standard->import({ wiki_file_chars => '-[:alnum:]+/.:_', # allow symlinks in the path leading to the srcdir (potentially insecure) #allow_symlinks_before_srcdir => 0, + # cookie control + #cookiejar => { + # file => '' + #}, + # set custom user agent string for outbound HTTP requests e.g. when fetching aggregated RSS feeds + #useragent => 'Wget/1.13.4 (linux-gnu)', ###################################################################### # core plugins @@ -207,7 +221,8 @@ IkiWiki::Setup::Standard->import({ ###################################################################### # format plugins - # (creole, highlight, hnb, html, mdwn, otl, rawhtml, textile, txt) + # (creole, highlight, hnb, html, mdwn, otl, po, rawhtml, rst, + # textile, txt) ###################################################################### # highlight plugin @@ -221,17 +236,58 @@ IkiWiki::Setup::Standard->import({ # mdwn plugin # enable multimarkdown features? #multimarkdown => 0, + # disable use of markdown discount? + # Testing on Ubuntu raring with libtext-markdown-discount-perl 0.04-1, + # libmarkdown2 2.1.5a-1, using libtext-markdown-discount-perl instead + # of libtext-markdown-perl introduces quite some (visible) differences + # in how certains things are being rendered, and I'm not interested in + # auditing all our *.mdwn files, so keep using libtext-markdown-perl. + nodiscount => 1, + + # po plugin + # master language (non-PO files) + #po_master_language => 'en|English', + # slave languages (translated via PO files) format: ll|Langname + #po_slave_languages => [qw{fr|Français es|Español de|Deutsch}], + # PageSpec controlling which pages are translatable + #po_translatable_pages => '* and !*/Discussion', + # internal linking behavior (default/current/negotiated) + #po_link_to => 'current', ###################################################################### - # misc plugins - # (filecheck) + # special-purpose plugins + # (osm, underlay) ###################################################################### + # osm plugin + # the default zoom when you click on the map link + #osm_default_zoom => 15, + # the icon shown on links and on the main map + #osm_default_icon => 'ikiwiki/images/osm.png', + # the alt tag of links, defaults to empty + #osm_alt => '', + # the output format for waypoints, can be KML, GeoJSON or CSV (one or many, comma-separated) + #osm_format => 'KML', + # the icon attached to a tag, displayed on the map for tagged pages + #osm_tag_default_icon => 'icon.png', + # Url for the OpenLayers.js file + #osm_openlayers_url => 'http://www.openlayers.org/api/OpenLayers.js', + # Layers to use in the map. Can be either the 'OSM' string or a type option for Google maps (GoogleNormal, GoogleSatellite, GoogleHybrid or GooglePhysical). It can also be an arbitrary URL in a syntax acceptable for OpenLayers.Layer.OSM.url parameter. + #osm_layers => { + # OSM => 'GoogleSatellite' + #}, + # Google maps API key, Google layer not used if missing, see https://code.google.com/apis/console/ to get an API key + #osm_google_apikey => '', + + # underlay plugin + # extra underlay directories to add + #add_underlays => [qw{}], + ###################################################################### # web plugins # (404, attachment, comments, editdiff, edittemplate, getsource, # google, goto, mirrorlist, remove, rename, repolist, search, - # theme, websetup, wmd) + # theme, userlist, websetup, wmd) ###################################################################### # attachment plugin @@ -253,6 +309,8 @@ IkiWiki::Setup::Standard->import({ #comments_allowauthor => 0, # commit comments to the VCS #comments_commit => 1, + # Restrict formats for comments to (no restriction if empty) + #comments_allowformats => 'mdwn txt', # getsource plugin # Mime type for returned source. @@ -261,6 +319,8 @@ IkiWiki::Setup::Standard->import({ # mirrorlist plugin # list of mirrors #mirrorlist => {}, + # generate links that point to the mirrors' ikiwiki CGI + #mirrorlist_use_cgi => 1, # repolist plugin # URIs of repositories containing the wiki's source @@ -272,6 +332,8 @@ IkiWiki::Setup::Standard->import({ # search plugin # path to the omega cgi program #omega_cgi => '/usr/lib/cgi-bin/omega/omega', + # use google site search rather than internal xapian index? + #google_search => 1, # theme plugin # name of theme to enable @@ -288,10 +350,10 @@ IkiWiki::Setup::Standard->import({ ###################################################################### # widget plugins # (calendar, color, conditional, cutpaste, date, format, fortune, - # graphviz, haiku, img, linkmap, listdirectives, map, more, - # orphans, pagecount, pagestats, poll, polygen, postsparkline, - # progress, shortcut, sparkline, table, template, teximg, toc, - # toggle, version) + # graphviz, haiku, headinganchors, img, linkmap, listdirectives, + # map, more, orphans, pagecount, pagestats, poll, polygen, + # postsparkline, progress, shortcut, sparkline, table, template, + # teximg, toc, toggle, version) ###################################################################### # calendar plugin @@ -309,6 +371,7 @@ IkiWiki::Setup::Standard->import({ #teximg_dvipng => '', # LaTeX prefix for teximg plugin #teximg_prefix => '\\documentclass{article} + #\\usepackage[utf8]{inputenc} #\\usepackage{amsmath} #\\usepackage{amsfonts} #\\usepackage{amssymb} @@ -321,11 +384,11 @@ IkiWiki::Setup::Standard->import({ ###################################################################### # other plugins # (aggregate, autoindex, brokenlinks, camelcase, ddate, embed, - # favicon, field, flattr, getfield, goodstuff, htmlbalance, - # localstyle, pagetemplate, pingee, pinger, prettydate, - # recentchanges, recentchangesdiff, relativedate, rsync, - # sidebar, smiley, sortnaturally, tag, testpagespec, underlay, - # ymlfront) + # favicon, field, filecheck, flattr, getfield, goodstuff, + # htmlbalance, localstyle, notifyemail, pagetemplate, pingee, + # pinger, prettydate, recentchanges, recentchangesdiff, + # relativedate, rsync, sidebar, smiley, sortnaturally, tag, + # testpagespec, trail, transient, ymlfront) ###################################################################### # aggregate plugin @@ -334,6 +397,10 @@ IkiWiki::Setup::Standard->import({ # allow aggregation to be triggered via the web? #aggregate_webtrigger => 0, + # autoindex plugin + # commit autocreated index pages + #autoindex_commit => 1, + # camelcase plugin # list of words to not turn into links #camelcase_ignore => [], @@ -377,10 +444,8 @@ IkiWiki::Setup::Standard->import({ tagbase => 'tag', # autocreate new tag pages? #tag_autocreate => 1, - - # underlay plugin - # extra underlay directories to add - #add_underlays => '', + # commit autocreated tag pages + #tag_autocreate_commit => 1, # ymlfront plugin # delimiters of YAML data @@ -216,13 +216,15 @@ a:hover padding: 0.5em 0em; line-height: 1; } -.newsitemcontent +.newsitemcontent, +.newsitemenclosure { padding-left: 0.2em; padding-top: 0.1em; } -.newsitemcontent p +.newsitemcontent p, +.newsitemenclosure p { margin: 0.3em; } diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index af5a786c..4cd4131f 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -3229,3 +3229,31 @@ In context of [[hurd/libports]], *Open Issues*, *IRC, freenode, #hurd, <braunr> i don't intend the hurd to run on top of it <braunr> the reason it's a rewrite is to fix a whole bunch of major issues in one go + + +## IRC, freenode, #hurd, 2014-03-03 + + <nalaginrut> braunr: x15 can be compiled successfully, is it possible to + run it on Hurd now? + <braunr> nalaginrut: it will never be + <braunr> x15 isn't a drop in mach replacement + <braunr> for now it's stalled until i have more free time :/ + <braunr> i need to rewrite virtual memory, and then implement ipc + <nalaginrut> oh, it's planed for standalone one? + <braunr> it's planned for a hurd clone + <nalaginrut> sounds bigger plan than I thought ;-) + <braunr> it is but not that much actually + <braunr> it's just i have really little free time currently .. + <braunr> and i chose to spend it on the hurd instead + <braunr> it's easier to fix bugs when you have little time, than think and + write big and difficult features like an smp scalable VM system + <nalaginrut> yes, I understand + <nalaginrut> it take huge time to think and design + <nalaginrut> and relative easier to fix the current one + <braunr> well, the whole thing is thought already + <braunr> what's hard is taking care of the details + <nalaginrut> well, you're so self-confident, to my experiences, even if all + the designs are in my mind, issues may make me change the original design + a lot ;-) + <nalaginrut> alright, I saw the key line, everything exists, just assemble + it diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn index 2b65956a..20c2cd44 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2011, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -19,7 +19,7 @@ and could perhaps be incorporated into that page. # SATA -IRC, freenode, +hurd, 2011-07-24 +## IRC, freenode, #hurd, 2011-07-24 <braunr> youpi: concerning the ide compatibility problem, it seems some bioses provide several modes @@ -31,3 +31,22 @@ IRC, freenode, +hurd, 2011-07-24 possibly with other IRQs <youpi> i.e. you need a PCI driver to handle that <braunr> ok + + +# IRC, freenode, #hurd, 2014-03-02 + + <teythoon> i bought a new mainboard for my hurd box + <teythoon> a ga-e350n + <teythoon> everything looks fine, grub loads gnumach, and, (afaict) it + starts it, but i see no single line printed by gnumach + <teythoon> the thing is, that this is the second board of this kind that i + bought + <teythoon> and on the first one, gnumach did work just fine + <teythoon> i tried it with a live cd, the same cd worked on the first + board, but does not on the second + <teythoon> also, i'm kind of surprised to see nothing at all from gnumach + <teythoon> i mean, it's loaded by grub + <youpi> teythoon: you could try to put *(char*)0xb8000 = 'X' starting from + c_boot_entry + <youpi> just to see at least something + <teythoon> i'll try, thanks :) diff --git a/news/2014-03-16-gsoc.mdwn b/news/2014-03-16-gsoc.mdwn new file mode 100644 index 00000000..7bcbcdca --- /dev/null +++ b/news/2014-03-16-gsoc.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2014 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta date="2014-03-16 15:45 UTC"]] + +The **Google Summer of Code 2014** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +[[community/GSoC]] and [[community/gsoc/project_ideas]] pages. diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 33635b80..496d2a06 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -1327,3 +1327,104 @@ 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 + + +# IRC, freenode, #hurd, 2014-03-11 + + <ltx> Does anyone have a distributed OS over GNU/hurd project running? + <ltx> (GNU/hurd has many of the utilities to make this easy, but it still + requires some more utilities for transparent computation) + <braunr> not at the moment, no + <braunr> and i consider our ipc inappropriate if you want system able to + run over heterogeneous hardware + <braunr> or rather, our RPCs + <ltx> I haven't spent the time, this is speculative (in the worse "let's do + everything magically!" way.) + <ltx> Just wondering if this exists outside of plan9 (which is limited in + some ways.) + <braunr> dragonflybsd had plans for a SSI + <braunr> there are ancient research systems that actually did the job + <braunr> such as amoeba + <braunr> here at the hurd, we just don't have the manpower, and the people + spending time on the project have other interests + <ltx> Yeah, that seems like a large problem. + <ltx> GNU/hurd is self hosting (in the "I like working on it" way), yes? + <ltx> I've done some work on it, but don't really know how nice it is. + <braunr> yes it is + <ltx> Working from a microkernel to add pseudo-SSI features to a bunch of + servers seems like a much more trivial task than, say, modifying TLK. + <braunr> posix conformance and stability are good enough that more than 70% + of debian packages build and most of them work fine + <braunr> tlk the linux kernel ? + <ltx> Yes. + <braunr> first time i see this acronym :) + <braunr> and yes i agree, a microkernel is much much more suited for that + <braunr> but then, i consider a microkernel better suited for practically + everything ... :) + <ltx> :) + <ltx> I'm wondering how to mix SSI with network-awareness. + <braunr> mach used to have a network server + <braunr> which would merely act as a proxy for capabilities + <braunr> network drivers were in kernel though + <ltx> That's the simple way of sharing the sources. + <ltx> I'm wondering how we can make a software stack that's network aware; + completely transparent SSI can lead to inefficiencies in userspace, as it + may do things the kernels won't expect. Having to deal with the network + through a network server is a headache. + <braunr> what kind of problems do you have in mind ? + <ltx> Still working on defining the problem. I think that's half the + problem. + <ltx> (For any problem.) + <ltx> Beyond that, it's just some coding ;) + <braunr> ok + <braunr> sounds interesting :) + <braunr> i'd love to see a modern SSI in action + <braunr> but that's really a secondary goal for me so glad to see someone + making this his primary goal + <braunr> doctoral thesis ? + <ltx> ... Undergrad who's been hacking away since grade school. + <braunr> heh :) + <ltx> 18 y/o sophomore at a respected technical college, dealing with + boredom :) + <braunr> well throroughly thinking about "defining the problem" is an + excellent reflex + <teythoon> :) stick around, the hurd is fun + <braunr> it does help fight boredom a lot indeed ...... ) + <braunr> :) + <cluck> maybe it'd be possible to port the relevant features from plan9 now + that there is a gpl'ed version + <teythoon> either way, we'd need network-transparent mach messaging + <teythoon> which mach messaging could do, but gnumach does not implement + this currently + <cluck> teythoon: afaiui if there was a proper 9fs2000 hurd server the rest + could be hidden behind the curtains + <teythoon> ah, well, that sounds like a 9p network filesystem translator + <cluck> teythoon: also iirc plan9 uses libmach for some things so i suppose + a port wouldn't be completely impossible + <teythoon> given that in plan9 everything is a file, that might be enough + to use plan9 services + <cluck> teythoon: yes, it'd be the easiest route (at least initially) i + believe + <teythoon> careful, lots of stuff is named mach-something + <cluck> bloody ernest mach and his damned famous-ness-ish + <cluck> =) + <teythoon> :D diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index ebbad1a4..26e0b770 100644 --- a/open_issues/arm_port.mdwn +++ b/open_issues/arm_port.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -152,29 +153,13 @@ architecture. <tschwinge> matty3269: I think that's better than starting on real hardware. <braunr> tschwinge: you can use -kernel with a multiboot binary now + +[[hurd/running/qemu#multiboot]]. + <braunr> tschwinge: and even creating iso images is so fast it's not any slower - <tschwinge> braunr: Yeah, I thought so, but never checked this out -- - recently I saw in qemu --help's output some »multiboot« thing flashing - by. :-) - <braunr> i think it only supports 32-bits executables though - <matty3269> braunr: Yeah, I just tried passing gnumach as the -kernel - parameter to qemu, but it segged qemu :S - <braunr> otherwise i'd be using it for x15 - <matty3269> qemu: fatal: Trying to execute code outside RAM or ROM at - 0xc0100000 - <braunr> how much ram did you give qemu ? - <matty3269> I used '-m 512' - <braunr> hum, so the -kernel option doesn't correctly implement elf loading - or something like that - <braunr> anyway, i'm not sure how well building gnumach on a non-hurd - system is supported - <braunr> so you may want to simply develop inside your VM for the time - being, and reboot - <matty3269> doing an objdump of it seems fine... - <braunr> ? + <braunr> ah, the gnumach executable is a correct elf image - <braunr> that's not the point <matty3269> Is there particular reason that mach is linked at 0xc0100000? <matty3269> or is that where it is expected to be in VM> <tschwinge> That's my understanding. @@ -192,21 +177,6 @@ architecture. <braunr> the .text section of linux on x86 actually starts at c1000000 (above 16 MiB, certainly to preserve as much dma-able memory since modern machines now have a lot more) - <tschwinge> Surely the GRUB multiboot loader is not that much used/tested? - <braunr> unfortunately, no - <braunr> matty3269: FYI, my kernel starts at 0xfff00000 :p - <matty3269> braunr: hmm, you could be right, I know it's arround there - someone - <matty3269> somewhere* - <matty3269> braunr: that's an interesting address :S - <matty3269> braunr: is that the PA address of the kernel or the VA inside a - process? - <braunr> the VA - <matty3269> hmm - <braunr> it can't be a PA - <braunr> such high addresses are normally device memory - <braunr> but don't worry, i have good reasons to have chosen this address - :) <matty3269> so with gnumach, does the boot-up sequence use PIC until VM is active and the kernel mapped to the linking address? <braunr> no @@ -217,37 +187,6 @@ architecture. <braunr> and uses offsets when accessing data <braunr> (which is why the kernel text is at 3 GiB + 1 MiB, and not 3 GiB) <matty3269> hmm, - <matty3269> gah, I need to learn x86 - <braunr> that would certainly help - <matty3269> I've just had a look at boothdr.S; I presume that there must be - something else that is executed before this to setup VM, switch to 32-bit - more etc...? - <matty3269> mode* - <braunr> have a look at the multiboot specification - <braunr> it sets protected mode - <braunr> but not paging - <braunr> (i mean, the boot loader does, before passing control to the - kernel) - <matty3269> Ah, I see - <tschwinge> matty3269: Multiboot should be documented in the GRUB package. - <matty3269> tschwinge: yep, got that, thanks - <matty3269> hmm, I can't find any reference to CR0 in gnumach so paging - must be enabled elsewhere - <matty3269> oh wait, found it - <braunr> $ git grep -i '\<cr0\>' - <braunr> i386/i386/proc_reg.h, linux/dev/include/asm-i386/system.h - <braunr> although i suspect only the first one is relevant to us :) - <matty3269> Yeah, that seems to have the setup code for paging :) - <matty3269> I'm still confused how it could run that without paging or PIC - though - <matty3269> I think I need to watch the boot sequence with qemu - <braunr> it's a bit tricky - <braunr> but actually simple - <braunr> 00:44 < braunr> either special sections are linked at physical - addresses - <braunr> 00:44 < braunr> or it relies on the fact that all executable code - uses near jumps - <braunr> that's really all there is <braunr> but you shouldn't worry about that i suppose, as the protocol between the boot loader and an arm kernel will certainly not be the saem <braunr> same* 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..68a04bfb 100644 --- a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn +++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn @@ -131,19 +131,9 @@ License|/fdl]]."]]"""]] at least -# Multiboot +# <a name="multiboot">Multiboot</a> -See also discussion about *multiboot* on [[arm_port]]. - - -## IRC, freenode, #hurd, 2013-10-09 - - <matlea01> I was just wondering - once gnumach is compiled and I have the - gnumach elf, is that bootable? I.e. can I use something like - "qemu-system-i386 -kernel gnumach"? - <kilobug> matlea01: you need something with multiboot support (like grub) - to provide the various bootstrap modules to the kernel - <matlea01> Ah, I see +See also [[hurd/running/qemu#multiboot]]. ## IRC, freenode, #hurd, 2014-02-24 @@ -173,32 +163,3 @@ See also discussion about *multiboot* on [[arm_port]]. <nalaginrut> you may use gdb for that <nalaginrut> for bochs, you don't have to use external debugger <congzhang> thanks for explain - <congzhang> does anyone succeed boot hurd with qemu multiboot boot - function? - <congzhang> with -kernel and -initrd command line parameter - <nalaginrut> I boot it with grub, in qemu, it's fine. Then I moved to - physical machine - <congzhang> boot with grub work for me too - <congzhang> I want to know whether it is possible to boot from qemu - directly - <congzhang> qemu can directly load kernel and hurd module for linux - <congzhang> nalaginrut: can you help to test whether hurd-console service - start will cause hurd black death? - <nalaginrut> I know qemu can boot Linux without MBR, but I don't know if - it's true for Hurd too - <nalaginrut> congzhang: I'm busy for other works now ;-) - <congzhang> ok, thks:) - <youpi> qemu's multiboot options don't seem to allow providing - ext2fs.static and ld.so, so I don't think it's possible - <congzhang> I try to do this, because hurd hurd-console cause system to - death very high frequency - <youpi> (because qemu doesn't implement all of multiboot) - <congzhang> qemu help show that's possible, -initrd support multi module - and parameter - <congzhang> en, I will check with them later - <youpi> how do you pass parameters to modules? - <youpi> ah, right, it's after the file name - <youpi> well, then simply try to pass the kernel, and the two modules - <youpi> with the same option as in the grub config templates - <youpi> it's fortunate that neither ext2fs nor exec need a comma on their - command line... diff --git a/open_issues/file_locking.mdwn b/open_issues/file_locking.mdwn index 563307a4..7dfbdb94 100644 --- a/open_issues/file_locking.mdwn +++ b/open_issues/file_locking.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,7 +11,25 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd open_issue_glibc]] -IRC, #hurd, 2010-12-31. +[[!toc]] + + +# Google Summer of Code Project Idea + +[[community/gsoc/project_ideas/File_Locking]]. + + +# visudo + +[[visudo]]. + + +# Existing Work + +[[!GNU_Savannah_patch 332]]. + + +# IRC, freenode, #hurd, 2010-12-31 <pinotree> youpi: i found the issue with python-apt <pinotree> s/with/of/ @@ -72,3 +91,8 @@ IRC, #hurd, 2010-12-31. <youpi> ah, no, on Linux flock is its own system call <youpi> (which is independant from lockf from the locking point of view, iirc) + + +# 2014-03-11 + +[[!message-id "1394523876.28244.11.camel@workhorse-peter-baumgarten-com"]]. diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 4dad229f..33041e71 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -210,17 +210,15 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc' make: *** [all] Error 2 - * <a id=missing>Missing interfaces, amongst many more.</a> + * <a id=missing>Missing Interfaces</a> - IRC, freenode, #hurd, 2014-02-25: + We have posted a [[Google Summer of Code project proposal|community/gsoc]]: - <tschwinge> youpi et al.: Is it a useful GSoC task to have the student - implement interfaces in glibc that we are currently missing? - <braunr> tschwinge: definitely - <braunr> posix_timers would be great - <youpi> tschwinge: probably + [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no + actions=yes]] - Many more are missing, some of which have been announced in `NEWS`, others + Many are missing for GNU Hurd, some of which have been announced in + [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others typically haven't (like new flags to existing functions). Typically, porters will notice missing functionaly. But in case you're looking for something to work on, here's a bit of a commented list, otherwise go @@ -1855,6 +1853,42 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 <braunr> teythoon: i think it should be in glibc <braunr> maybe in mach/ + * [[POSIX file record locking|file_locking]] + + * <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 + + * <a name="posix_timers">POSIX Timers</a> + + `timer_create`, `timer_delete`, [[`clock_gettime`|clock_gettime]], and + so on. + 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..cef16734 100644 --- a/open_issues/nightly_builds_deb_packages.mdwn +++ b/open_issues/nightly_builds_deb_packages.mdwn @@ -67,33 +67,23 @@ See also [[nightly_builds]]. <teythoon> there has been talk here the other day about using qemus multiboot capabilities to directly boot the hurd -[[debugging_gnumach_startup_qemu_gdb]], *Multiboot* - - <teythoon> i always wanted to try that out - <pere> the jenkins rules to test the install uses --kernel, --initrd and - --append in qemu to specify the preseed file. without a similar method - to boot hurd, it will be hard to automate the test. rewriting the iso - might be an option, but not a very nice one. - <teythoon> i believe that it is possible to use those options to boot a - hurd - <teythoon> i'll report back to you +[[hurd/running/qemu#multiboot]]. + +For d-i purposes, you'll additionally need: + + $ wget http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/current/initrd.gz + +..., and to the `--initrd` option prepend `'initrd.gz $(ramdisk-create)',` +before the `ext2fs.static`, and refer the latter to `gunzip:device:rd0` instead +of `device:hd0s1`. + <pere> I tried adding an url= option to grub when booting the installer, but it seem to be ignored. - <pere> I suspect it did not make it to /proc/cmdline, but am not sure. - <teythoon> um - <teythoon> it should - <pere> could be. I am unable to get a shell in the installer, so I do not - know. - <teythoon> root@pluto ~ # cat /proc/cmdline - <teythoon> root=device:hd0s1 - <teythoon> oh ? select expert install, then spawn a shell or something <pere> perhaps the preseed udeb is missing, or the network support was enabled after preseed looked for the file? <teythoon> uh, i don't know about that stuff, youpi creates the d-i images <pere> ok. seem to me that the d-i images do not support preseeding at the moment. - <teythoon> pere: when i try to use qemus multiboot support to boot the - hurd, qemu crashes :/ <teythoon> youpi: ^ did you succeed? if so, can you share how? <pere> teythoon: nope, I concluded it didn't work, and left it to other to fix. :) @@ -108,3 +98,650 @@ 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-28 + + <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 + <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> 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 + <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) + + <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/#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 + <youpi> unfortunately I had to apply some patches + <youpi> first in d-i because isc-dhcp doens't work -> use the debian-ports + version + <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 + + <gg0> anything missing here? + http://people.debian.org/~sthibault/hurd-i386/installer/README-d-i + <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> 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) + + +## IRC, OFTC, #debian-hurd, 2014-03-10 + + <gg0> tschwinge: i just meant Debian Jenkins provides (hopefully for hurd + too) continuos testing of debian installer, it doesn't produce .debs 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 diff --git a/open_issues/visudo.mdwn b/open_issues/visudo.mdwn index e9892e33..4e87fd8d 100644 --- a/open_issues/visudo.mdwn +++ b/open_issues/visudo.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -16,7 +16,7 @@ visudo does not work: /etc/sudoers is busy, try again later -Apparently there is some locking that sudo does which does not +Apparently there is some [[file_locking]] that sudo does which does not work. Uninvestigated for now. One can just edit the /etc/sudoers file and take care of correctness by hand. diff --git a/public_hurd_boxen/installation/darnassus.mdwn b/public_hurd_boxen/installation/darnassus.mdwn index 8cb8f619..907be198 100644 --- a/public_hurd_boxen/installation/darnassus.mdwn +++ b/public_hurd_boxen/installation/darnassus.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -17,7 +17,7 @@ License|/fdl]]."]]"""]] * ikiwiki libcgi-session-perl libtext-csv-perl libcgi-formbuilder-perl libauthen-passphrase-perl libnet-openid-consumer-perl - liblwpx-paranoidagent-perl libterm-readline-gnu-perl libgravatar-url-perl + libterm-readline-gnu-perl libgravatar-url-perl librpc-xml-perl libtext-wikiformat-perl libhighlight-perl perlmagick graphviz texinfo @@ -27,6 +27,14 @@ License|/fdl]]."]]"""]] * libyaml-perl libyaml-syck-perl (for ikiwiki's YAML field plugins) + * libtext-markdown-perl (used instead of libtext-markdown-discount-perl) + + Make sure that liblwpx-paranoidagent-perl is not installed; OpenID logins + with fail otherwise: *no_identity_server: Could not determine ID provider + from URL*. Issue discovered on 2014-02-28, but unclear since when it did + actually occur. Nothing in the apache logs. Not fixed by the update to + ikiwiki 3.20140227. + * gitweb highlight sudo ln -s ~hurd-web/hurd-web.git /var/lib/git/ diff --git a/shortcuts.mdwn b/shortcuts.mdwn index 1347e853..978cca6c 100644 --- a/shortcuts.mdwn +++ b/shortcuts.mdwn @@ -7,33 +7,33 @@ Some examples of using shortcuts include: \[[!google foo]] \[[!wikipedia War_of_1812]] \[[!debbug 12345]] - Check the \[[!cia ikiwiki desc="CIA page for %s"]]. + Check the \[[!google ikiwiki desc="google search for %s"]]. This page controls what shortcut links the wiki supports. -* [[!shortcut name=google url="http://www.google.com/search?q=%s"]] +* [[!shortcut name=google url="https://encrypted.google.com/search?q=%s"]] * [[!shortcut name=archive url="http://web.archive.org/*/%S"]] -* [[!shortcut name=gmap url="http://maps.google.com/maps?q=%s"]] -* [[!shortcut name=gmsg url="http://groups.google.com/groups?selm=%s"]] -* [[!shortcut name=wikipedia url="http://en.wikipedia.org/wiki/%S"]] -* [[!shortcut name=wikitravel url="http://wikitravel.org/en/%s"]] -* [[!shortcut name=wiktionary url="http://en.wiktionary.org/wiki/%s"]] +* [[!shortcut name=gmap url="https://maps.google.com/maps?q=%s"]] +* [[!shortcut name=gmsg url="https://groups.google.com/groups?selm=%s"]] +* [[!shortcut name=wikipedia url="https://en.wikipedia.org/wiki/%W"]] +* [[!shortcut name=wikitravel url="https://wikitravel.org/en/%s"]] +* [[!shortcut name=wiktionary url="https://en.wiktionary.org/wiki/%s"]] * [[!shortcut name=debbug url="http://bugs.debian.org/%S" desc="Debian bug #%s"]] -* [[!shortcut name=deblist url="http://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] +* [[!shortcut name=deblist url="https://lists.debian.org/debian-%s" desc="debian-%s@lists.debian.org"]] * [[!shortcut name=debpkg url="http://packages.debian.org/%s"]] * [[!shortcut name=debpkgsid url="http://packages.debian.org/sid/%s"]] * [[!shortcut name=debpts url="http://packages.qa.debian.org/%s"]] -* [[!shortcut name=debmsg url="http://lists.debian.org/msgid-search/%s"]] +* [[!shortcut name=debmsg url="https://lists.debian.org/msgid-search/%s"]] * [[!shortcut name=debrt url="https://rt.debian.org/Ticket/Display.html?id=%s"]] * [[!shortcut name=debss url="http://snapshot.debian.org/package/%s/"]] - * Usage: `\[[!debss package]]` or `\[[!debss package/version]]`. See http://snapshot.debian.org for details. -* [[!shortcut name=debwiki url="http://wiki.debian.org/%s"]] + * Usage: `\[[!debss package]]` or `\[[!debss package/version]]`. See <http://snapshot.debian.org/> for details. +* [[!shortcut name=debwiki url="https://wiki.debian.org/%s"]] * [[!shortcut name=fdobug url="https://bugs.freedesktop.org/show_bug.cgi?id=%s" desc="freedesktop.org bug #%s"]] * [[!shortcut name=fdolist url="http://lists.freedesktop.org/mailman/listinfo/%s" desc="%s@lists.freedesktop.org"]] -* [[!shortcut name=gnomebug url="http://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]] -* [[!shortcut name=linuxbug url="http://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]] +* [[!shortcut name=gnomebug url="https://bugzilla.gnome.org/show_bug.cgi?id=%s" desc="GNOME bug #%s"]] +* [[!shortcut name=linuxbug url="https://bugzilla.kernel.org/show_bug.cgi?id=%s" desc="Linux bug #%s"]] * [[!shortcut name=mozbug url="https://bugzilla.mozilla.org/show_bug.cgi?id=%s" desc="Mozilla bug #%s"]] -* [[!shortcut name=gnulist url="http://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]] +* [[!shortcut name=gnulist url="https://lists.gnu.org/mailman/listinfo/%s" desc="%s@gnu.org"]] * [[!shortcut name=marcmsg url="http://marc.info/?i=%s"]] * [[!shortcut name=marclist url="http://marc.info/?l=%s"]] * [[!shortcut name=gmane url="http://dir.gmane.org/gmane.%s" desc="gmane.%s"]] @@ -43,7 +43,7 @@ This page controls what shortcut links the wiki supports. * [[!shortcut name=hoogle url="http://haskell.org/hoogle/?q=%s"]] * [[!shortcut name=iki url="http://ikiwiki.info/%S/"]] * [[!shortcut name=ljuser url="http://%s.livejournal.com/"]] -* [[!shortcut name=rfc url="http://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]] +* [[!shortcut name=rfc url="https://www.ietf.org/rfc/rfc%s.txt" desc="RFC %s"]] * [[!shortcut name=c2 url="http://c2.com/cgi/wiki?%s"]] * [[!shortcut name=meatballwiki url="http://www.usemod.com/cgi-bin/mb.pl?%s"]] * [[!shortcut name=emacswiki url="http://www.emacswiki.org/cgi-bin/wiki/%s"]] @@ -53,18 +53,24 @@ This page controls what shortcut links the wiki supports. * [[!shortcut name=gpg url="http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&exact=on&search=0x%s"]] * [[!shortcut name=perldoc url="http://perldoc.perl.org/search.html?q=%s"]] * [[!shortcut name=whois url="http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain"]] -* [[!shortcut name=cve url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]] -* [[!shortcut name=cia url="http://cia.vc/stats/project/%s"]] -* [[!shortcut name=ciauser url="http://cia.vc/stats/user/%s"]] -* [[!shortcut name=flickr url="http://www.flickr.com/photos/%s"]] +* [[!shortcut name=cve url="https://cve.mitre.org/cgi-bin/cvename.cgi?name=%s"]] +* [[!shortcut name=flickr url="https://secure.flickr.com/photos/%s"]] * [[!shortcut name=man url="http://linux.die.net/man/%s"]] -* [[!shortcut name=ohloh url="http://www.ohloh.net/projects/%s"]] +* [[!shortcut name=ohloh url="https://www.ohloh.net/p/%s"]] +* [[!shortcut name=cpanrt url="https://rt.cpan.org/Ticket/Display.html?id=%s" desc="CPAN RT#%s"]] +* [[!shortcut name=novellbug url="https://bugzilla.novell.com/show_bug.cgi?id=%s" desc="bug %s"]] +* [[!shortcut name=ubupkg url="http://packages.ubuntu.com/%s"]] +* [[!shortcut name=mozillazinekb url="http://kb.mozillazine.org/%s"]] +* [[!shortcut name=freebsdwiki url="http://wiki.freebsd.org/%s"]] +* [[!shortcut name=hackage url="http://hackage.haskell.org/package/%s"]] To add a new shortcut, use the `shortcut` [[ikiwiki/directive]]. In the url, "%s" is replaced with the text passed to the named shortcut, after [[!wikipedia url_encoding]] -it, and '%S' is replaced with the raw, non-encoded text. The optional -`desc` parameter controls the description of the link. +it, and '%S' is replaced with the raw, non-encoded text. +Additionally, `%W` is replaced with the text encoded just right for +Wikipedia. The optional `desc` parameter controls the description of +the link. Remember that the `name` you give the shortcut will become a new [[ikiwiki/directive]]. Avoid using a `name` that conflicts diff --git a/sidebar.mdwn b/sidebar.mdwn index e8b69a93..a5daebe5 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 +Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -11,6 +11,14 @@ License|/fdl]]."]]"""]] Welcome to... [[!img /logo/boxes-redrawn.png link=/logo]] ... the GNU Hurd! +[[!template id=highlight text="""**Breaking News** + +--- + +The **Google Summer of Code 2014** is on! If you're a student, consider +applying for a GNU Hurd project -- details to be found on our +[[community/GSoC]] and [[community/gsoc/project_ideas]] pages."""]] + --- * **[[Home|/index]]** diff --git a/user/pochu.mdwn b/user/pochu.mdwn index 18e90de3..545dbfed 100644 --- a/user/pochu.mdwn +++ b/user/pochu.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -83,7 +83,7 @@ fixing them. ### May 19 - May 26 * Read [MIG - The MACH Interface Generator](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) -* Worked on bug 28934. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. +* Worked on bug [[!GNU_Savannah_bug 28934]]. Send [patches](http://lists.gnu.org/archive/html/bug-hurd/2010-05/msg00108.html) for review. * Requested GNU libc copyright papers to the FSF again since they didn't arrive the first time. ### May 12 - May 19 @@ -95,7 +95,7 @@ fixing them. ### May 5 - May 12 * Read http://www.gnu.org/software/hurd/hurd-paper.html * Improved the linkat() patch -* Fixed the issues mentioned in bug 28934, but after doing so I realized +* Fixed the issues mentioned in bug [[!GNU_Savannah_bug 28934]], but after doing so I realized that wouldn't work well. The only good solution is to pass file_name from execve() to the exec server, so we need new RPCs. @@ -105,7 +105,7 @@ fixing them. ### Before April 28 * Investigated the glib's gtester problem and tracked it down: - [bug 28934](https://savannah.gnu.org/bugs/?28934). Prepared a patch + [[!GNU_Savannah_bug 28934]]. Prepared a patch but it's not good. * [glib's garray test timeouts on Hurd](https://bugzilla.gnome.org/show_bug.cgi?id=568760). The tests passes if the timeout is increased. The current upstream timeout |