diff options
24 files changed, 303 insertions, 328 deletions
diff --git a/.templates/autotag.tmpl b/.templates/autotag.tmpl index 6af818b3..de885b73 100644 --- a/.templates/autotag.tmpl +++ b/.templates/autotag.tmpl @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!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 diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn index 7e355ec4..e6f07822 100644 --- a/community/gsoc.mdwn +++ b/community/gsoc.mdwn @@ -11,20 +11,20 @@ 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 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 @@ -37,17 +37,24 @@ 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. It is a good idea to get familiar with the GNU Hurd, by reading some of our [[documentation]], and by using a GNU/Hurd system. It is also a good idea to -send in some basic patches (this has already been mentioned in our -[[student_application_form]]), or discuss with us the principal steps you're -planning on doing in your intended work area. Of course, we don't expect you +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 @@ -56,16 +63,14 @@ how to do `X`, can someone please help me?* And, as we're not working next to each other in a conventional office or university setup, we'll need to establish and get used to different communication channels. -[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013). - <!-- +[Timeline](http://www.google-melange.com/gsoc/events/google/gsoc2013). As boring as it is, but the next step is waiting: we will have to wait for Google to announce the number of slots that the whole GNU project gets, and we'll be discussing with our GNU peers about how to split these up among all the GNU subprojects. - --> @@ -75,8 +80,10 @@ We have a list of [[project_ideas]], and students are likewise encouraged to submit their own project proposals. Please follow our [[student_application_form]]. +<!-- Then, don't forget to visit <http://www.google-melange.com/>, and press the button for submitting your proposal. +--> Please read up about [[contributing]] in general, and please ask any questions you might have, on the [[mailing_lists]], or on [[IRC]], for example at one of diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn index b7de141b..d3e43dd6 100644 --- a/community/gsoc/2013/hacklu.mdwn +++ b/community/gsoc/2013/hacklu.mdwn @@ -1177,23 +1177,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will figure out it. - <teythoon> btw, what about the copyright assignment process? - <tschwinge> teythoon, hacklu: You still haven't heard from the FSF about - your copyright assignments? What's the latest you have heard? - <hacklu> tschwinge: I have wrote a emali to ask for that, but no reply. - <teythoon> tschwinge: last and only response I got was on July 1st, the - last ping with explicit request for confirmation was on July the 12th - <tschwinge> hacklu: When did you send this email? - <hacklu> tschwinge: last week. - <tschwinge> teythoon: I suggest you send another inquiry, and please put me - in CC. And if there'S no answer within a couple days (well, I'm away - until Monday...), I'll follow up. - <tschwinge> hacklu: Likewise for you; depending on when exactly ;-) you - sent the last email. (Always allow for a few days until you exect an - answer, but if nothing happend within a week for such rather simple - administrative tasks, better ask again, unfrotunately.) - <hacklu> tschwinge:ok , I will email more - <hacklu> how to understand the asyn RPC? <braunr> hacklu: hm ? <hacklu> for instance, [hurd]/proc/main.c proc_server is loop in listening @@ -1619,25 +1602,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: <youpi> I'd rather let tschwinge comment on this <hacklu> youpi: ok :) - <youpi> how about the copyright assignments? did hacklu or teythoon receive - any answer? - <teythoon> youpi: I did, the copyright clerk told me that he finally got my - papers and that everything is in order now - <youpi> few! - <youpi> s/f/ph - <youpi> teythoon: you mean all steps are supposed to be done now, or is he - doing the last steps? I don't see your name in the copyright folder yet - <teythoon> youpi: well, he said that he had the papers and they are about - to be signed - <youpi> teythoon: ok, so it's not finished, that's why your name is not on - the list yet - <youpi> this paper stuff is really a pain - <hacklu> youpi: I haven't got any answer from FSF now. - <youpi> did you ping them recently? - <hacklu> I have pinged 2 week ago. - <hacklu> what you mean of ping? I just write an email to him. Is it enough? - <youpi> yes - # IRC, freenode, #hurd, 2013-08-12 @@ -1733,9 +1697,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]: < hacklu> hello everyone, this is my week report. http://hacklu.com/blog/gsoc-weekly-report10-174/ - < hacklu> btw, my FSF copyright assignment has been concepted. They guy - said, they have recived my mail for a while but forget to handle it. - < hacklu> but now I face a new problem, when I typed the first continue command, gdb will continue all the breakpoint, and the inferior will run until normally exit. diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn index 83e97bc7..87250c62 100644 --- a/community/gsoc/2013/nlightnfotis.mdwn +++ b/community/gsoc/2013/nlightnfotis.mdwn @@ -429,25 +429,6 @@ License|/fdl]]."]]"""]] <tschwinge> nlightnfotis: But before doing that, please do the diff first, so that we know (hopefully) where the erroneous build results were coming from. - <nlightnfotis> considering the Copyright assignment files, I have sent them - from day 1 (that is the 20th of June). I have not heard anything about - those documents to date (sadly) - <nlightnfotis> what's worst is that although I have a reference number to - track those documents, their (greek postal office) tracking service sucks - so badly, that one day it's offline, the next it suggests it can't find - the object in their database, the next it says it is still in the local - post office - <nlightnfotis> let me check it out now - <nlightnfotis> still nothing from their online service - <nlightnfotis> let me call them - <nlightnfotis> tschwinge: I called the post office regarding the copyright - papers. They told me that the same day (the 20th of June) it left from - Herakleion, Crete to Athens and the same day it must have left the - country heading towards the US. They also told me it takes about 1 week - for it to arrive. - <tschwinge> nlightnfotis: OK, so probably waiting at the FSF office to be - processed. Let's allow for some more time. After all, this is not - critical for your progress. # IRC, freenode, #hurd, 2013-07-10 @@ -826,25 +807,6 @@ License|/fdl]]."]]"""]] worker threads are actually never destroyed on debian (because of a debian specific patch) - <teythoon> youpi, nlightnfotis, hacklu_: btw, what about the copyright - assignment process - <tschwinge> nlightnfotis just got his on file, so there is progress. - <tschwinge> I have email from Donald R Robertson III - <copyright-clerk@fsf.org> about that -- but it is not yet present in the - FSF copyright.list file... - <tschwinge> I think I received that email because I was CCed on - nlightnfotis' submission. - <nlightnfotis> tschwinge: I have got the papers, and they were signed by - the FSF. They stated delivery date 11 of July, but the documents were - signed on the 10th of July :P - <tschwinge> Ah, no, I received it via hurd-maintainers@gnu.org -- and the - strange thing is that not all assignments that got processed got sent - there... - <tschwinge> At the recent GNU Tools Cauldron we also discussed this in the - GCC context; and their experience was the very same. Emails get lost, - and/or take ages to be processed, etc. - <tschwinge> It seems the FSF is undermanned. - # IRC, freenode, #hurd, 2013-07-27 diff --git a/community/meetings.mdwn b/community/meetings.mdwn index c20220d6..1d8199ad 100644 --- a/community/meetings.mdwn +++ b/community/meetings.mdwn @@ -13,16 +13,13 @@ License|/fdl]]."]]"""]] # Upcoming - -## In the Future - - * [[FOSDEM_2013]] - * [[Self-organised]] + * [[FOSDEM_2014]] # Past * [[GNU Hackers Meeting, 2013, Paris|ghm2013]] + * [[FOSDEM_2013]] * [[GNU Hackers Meeting, 2012, Düsseldorf|ghm2012]] * [[FOSDEM_2012]] * [[FrOSCon_2011]] diff --git a/community/meetings/fosdem_2013.mdwn b/community/meetings/fosdem_2013.mdwn index 30860cb6..0ac36838 100644 --- a/community/meetings/fosdem_2013.mdwn +++ b/community/meetings/fosdem_2013.mdwn @@ -12,7 +12,7 @@ License|/fdl]]."]]"""]] <http://fosdem.org/2013> -FOSDEM will take place on February 2th/3th at the Université Libre de +FOSDEM will take place on February 2nd/3rd at the Université Libre de Bruxelles. diff --git a/community/meetings/fosdem_2014.mdwn b/community/meetings/fosdem_2014.mdwn new file mode 100644 index 00000000..1379968e --- /dev/null +++ b/community/meetings/fosdem_2014.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2012, 2013 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 title="FOSDEM 2014"]] + +<http://fosdem.org/2014> + +FOSDEM will take place on February 1st/2nd at the Université Libre de +Bruxelles. + + +# Who and When + +[[!table class="table_style_1" data=""" +"Name","Attending","Arrival","Return" +"""]] + + +# Devroom: Microkernel and component-based operating systems + +[[!message-id desc="Announcement and CfP" +"5255453A.70302@os.inf.tu-dresden.de"]]. diff --git a/community/meetings/self-organised.mdwn b/community/meetings/self-organised.mdwn deleted file mode 100644 index 1403c115..00000000 --- a/community/meetings/self-organised.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 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 title="Self-organised meeting"]] - -This meeting will be held in a to-be-determined place, at a to-be-determined time. This page hopes to help finding a good time and place, and finding out who wants to come. - -# Who wants to come? - -Please add yourself here. - -* [[Bas_Wijnen|baswijnen]] (no preference for specific times) -* [[Thomas_Schwinge|tschwinge]] -* [[Tom_Bachmann|tombachmann]] (weekend in the middle of germany would be preferred) -* [[Gianluca_Guida|GianlucaGuida]] (wherever, whenever) -* [[Samuel_Thibault|SamuelThibault]] (wherever, whenever) - -# Who will come? - -* (to be filled in when the date is set) - -# When is a good time? - -Please add any suggestions here, and add to your name above if that time is good for you. - -# Where is a good place? - -## Somewhere in Germany - -This likely has the benefit of being relatively close to most people - -<http://www.linuxhotel.de/community.html> might be a suitable venue at very -reasonable pricing. - -## Somewhere in Italy - -This likely has the benefit of better weather. ;-) - -## Venice (Italy) - -This certainly has the benefit of being in an awesome place. :-) Perhaps we shouldn't care too much about that, since we're mostly busy with ourselves anyway. Or perhaps we should: beauty helps creativity (wow, I should use this as my next catch-phrase to convince a girl to stay with me: I will fail again, but with style! Gianluca). - -# What will we do? - -There will be talks with discussions: - -* Bas will give a talk about Capability-microkernel-based operating systems, with an emphasis on how this can be useful for the Hurd. The talk hopes to get people enthousiastic for the concept, and it will be tried to keep it interesting for people who are not yet familiar with the concepts. diff --git a/config_edittemplate/open_issue_page.mdwn b/config_edittemplate/open_issue_page.mdwn index ae85efde..704c9423 100644 --- a/config_edittemplate/open_issue_page.mdwn +++ b/config_edittemplate/open_issue_page.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!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 diff --git a/config_edittemplate/regular_page.mdwn b/config_edittemplate/regular_page.mdwn index 858988d1..a479268f 100644 --- a/config_edittemplate/regular_page.mdwn +++ b/config_edittemplate/regular_page.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!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 diff --git a/contributing/web_pages/news/skeleton.mdwn b/contributing/web_pages/news/skeleton.mdwn index 749a42bb..d45b87d1 100644 --- a/contributing/web_pages/news/skeleton.mdwn +++ b/contributing/web_pages/news/skeleton.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!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 diff --git a/copyright.mdwn b/copyright.mdwn index a790521d..34719931 100644 --- a/copyright.mdwn +++ b/copyright.mdwn @@ -1,2 +1,2 @@ Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, -2013 The Contributing Authors +2013, 2014 The Contributing Authors diff --git a/history.mdwn b/history.mdwn index 9ae1efd0..7cf5cd6e 100644 --- a/history.mdwn +++ b/history.mdwn @@ -11,6 +11,8 @@ License|/fdl]]."]]"""]] [[!tag stable_URL]] +[[!toc]] + Richard Stallman (RMS) started GNU in 1983, as a project to create a complete free operating system. In the text of the [GNU Manifesto](http://www.gnu.org/gnu/manifesto.html), he @@ -56,7 +58,6 @@ Linux|hurd-and-linux]], where he mentions that the FSF started developing the Hurd in 1990. As of [Gnusletter, Nov. 1991], the Hurd (running on Mach) is GNU's official kernel. ---- # Announcements @@ -64,42 +65,62 @@ These are all the announcements made over the years. Most of them were either sent to the <A HREF="news:gnu.announce">gnu.announce</A> news group or Hurd interest mailing lists. - * [[GNU Hurd 0.5, GNU Mach 1.4, GNU MIG 1.4 released|news/2013-09-27]] - * [[hurd-flash15]] -- Release 0.2 announcement (complete GNU system) - * [[hurd-flash14]] -- Release 0.2 announcement (Hurd) - * [[hurd-flash13]] -- Test release announcement (Aug 96) - * [[hurd-flash12]] -- Test release status (Jul 96) + * [[hurd-announce]] -- GNU Hurd announcement, May 91 + * [[hurd-announce2]] -- GNU Hurd announcement, Nov 93 + * [[hurd-flash]] -- News flash, Apr 94 -- it boots! + * [[hurd-flash2]] -- News flash, May 94 + * [[hurd-flash3]] -- News flash, Jul 94 -- emacs runs! + * [[hurd-flash4]] -- News flash, Aug 94 + * [[hurd-flash5]] -- News flash, Sep 94 -- gcc runs! + * [[hurd-flash6]] -- News flash, Nov 94 + * [[hurd-flash7]] -- New Snapshot, Apr 95 + * [[hurd-flash8]] -- New Snapshot, Jul 95 -- ext2fs support + * [[hurd-flash9]] -- News Flash, Nov 95 -- ftp works! + * [[hurd-flash10]] -- New Snapshot, Apr 96 -- NFS and lots else works! * [[hurd-flash11]] -- Binary image available, Apr 96 This and [NetBSD](http://www.netbsd.org/) boot flopies should be enough to get a working GNU/Hurd system! - * [[hurd-flash10]] -- New Snapshot, Apr 96 -- NFS and lots else works! - * [[hurd-flash9]] -- News Flash, Nov 95 -- ftp works! - * [[hurd-flash8]] -- New Snapshot, Jul 95 -- ext2fs support - * [[hurd-flash7]] -- New Snapshot, Apr 95 - * [[hurd-flash6]] -- News flash, Nov 94 - * [[hurd-flash5]] -- News flash, Sep 94 -- gcc runs! - * [[hurd-flash4]] -- News flash, Aug 94 - * [[hurd-flash3]] -- News flash, Jul 94 -- emacs runs! - * [[hurd-flash2]] -- News flash, May 94 - * [[hurd-flash]] -- News flash, Apr 94 -- it boots! - * [[hurd-announce2]] -- GNU Hurd announcement, Nov 93 - * [[hurd-announce]] -- GNU Hurd announcement, May 91 - ---- - - * [History - 1997-2003](http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00718.html) - -- personal view of Marcus Brinkmann about Hurd development in 1997-2003. - ---- - - * [[Port_to_another_microkernel]] + * [[hurd-flash12]] -- Test release status (Jul 96) + * [[hurd-flash13]] -- Test release announcement (Aug 96) + * [[!message-id desc="GNU Hurd 0.1" + "199609070249.WAA24297@geech.gnu.ai.mit.edu"]] (1996-09-06) + * [[!message-id desc="GNU Mach 1.0" + "199704142043.QAA01894@churchy.gnu.ai.mit.edu"]] (1997-04-14) + * [[!message-id desc="GNU Mach 1.1" + "199705091753.NAA15557@sugar-bombs.gnu.ai.mit.edu"]] (1997-05-09) + * [[!message-id desc="GNU Mach 1.1.1" + "199705121633.MAA26409@sugar-bombs.gnu.ai.mit.edu"]] (1997-05-12) + * [[!message-id desc="GNU Mach 1.1.2" + "199706102159.RAA13943@churchy.gnu.ai.mit.edu"]] (1997-06-10?) + * [[hurd-flash14]] -- Release 0.2 announcement (Hurd) + * [[hurd-flash15]] -- Release 0.2 announcement (complete GNU system) + * [[!message-id desc="GNU 0.2" + "199706162021.QAA18370@sugar-bombs.gnu.ai.mit.edu"]] (1997-06-16) + * [[!message-id desc="GNU MIG 1.0.1" + "199812040849.DAA07660@baalperazim.frob.com"]] (1998-12-04) + * [[!message-id desc="GNU Mach 1.2" + "199906211918.PAA26822@x15-cruise-basselope.mit.edu"]] (1999-06-21) + * [[!message-id desc="GNU MIG 1.1" "199906231741.NAA46739@pusey.mit.edu"]] + (1999-06-23) + * [[!message-id desc="GNU MIG 1.2" "20010622215446.I6130@212.23.136.22"]] + (2001-06-22) + * [[!message-id desc="GNU MIG 1.3" + "20020308220603.A90E61B9C4@perdition.linnaean.org"]] (2002-03-08) + * [[!message-id desc="GNU Mach 1.3" + "20020527203155.88DBE1BA15@perdition.linnaean.org"]] (2002-05-27) + * [[!message-id desc="GNU MIG 1.3.1" + "20020830194413.GA6819@outpost.dnsalias.org"]] (2002-08-30) + * [[GNU Hurd 0.5, GNU Mach 1.4, GNU MIG 1.4 released|news/2013-09-27]] + (2013-09-27) ---- # An Incomplete GNU Hurd Timeline * 1997: GNU Hurd 0.2. + * First attempts to [[port_to_another_microkernel]] + * Personal view of Marcus Brinkmann about [[!message-id desc="Hurd + development in 1998-2003" + "87mzkvx7u8.wl%marcus.brinkmann@ruhr-uni-bochum.de"]] * 2002: GNU MIG 1.3, libio-based glibc, GNU Mach 1.3, Hurd L4 starts, work on the transition from cthreads to pthreads starts, Hurd installation party in Heidelberg, Toronto Hurd User Group meeting, Presentation at EpX in Paris diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index 36d18fbb..09dfb821 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -36,6 +36,26 @@ For more details, see section 2.3 of the [[critique]]. [[!tag open_issue_hurd]] +## IRC, freenode, #hurd, 2013-09-26 + + <braunr> teythoon: hum, i just saw something disturbing + <braunr> teythoon: to isolate the leak, i created my own proc directory + <braunr> and the mtab translators it spawns seem to be owned by root oO + <teythoon> braunr: but how is that possible? are you sure? have you checked + with 'ids'? + <braunr> no i'm not sure + <braunr> also, ext2fs seems to ignore --writable when started as a passive + translator + <braunr> < teythoon> braunr: but how is that possible? + <braunr> messup with passive translators i guess + <braunr> teythoon: actually, it looks like it has effective/available id + <braunr> it has no* + <braunr> this feature doesn't map well in unix + <teythoon> braunr: ah yes, htop doesn't handle this well and shows root + indeed, our ps shows - as username + <braunr> yes + + ## IRC, freenode, #hurd, 2013-09-28 <braunr> mhmm diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index ef5e8cbd..bac32906 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -2111,6 +2111,10 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. ## Memory Leak +Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb +(libdiskfs), and 2013-10-04 Hurd commit +98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs). + ### IRC, freenode, #hurd, 2013-09-18 <braunr> ext2fs is using a ginormous amount of memory on darnassus since i @@ -2227,23 +2231,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> which is why i'm mentioning it <braunr> :) <braunr> i'll try to reproduce the assertion - <pinotree> libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ← - this one? - <braunr> yes - <braunr> hm no - <pinotree> oho - <braunr> no, not that one - <pinotree> no-oho - <braunr> well maybe by side effect - <braunr> but i doubt it - <pinotree> iirc you constantly get that when building ustr - <braunr> (e.g., because the object was freed and reallocated quickly, - st_size has been reset, something like that) - <braunr> is ustr a package ? - <pinotree> yes - <braunr> ok - <braunr> thanks - <braunr> pinotree: indeed, it's still present <braunr> pinotree: actually, after a more in-depth look, reference counting looks valid before the fix too <pinotree> ok, thanks for checking @@ -2253,65 +2240,10 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> malloc <pinotree> ok <braunr> i suspect the code doesn't handle memory failure well - <pinotree> iirc the ustr tests are mostly disk-intensive - <braunr> this one is really about enonmem - <braunr> enomem - <braunr> i'll make ext2fs print a stack trace - <pinotree> (might be wrong, but did not investigate further, sorry) - <braunr> no worries - <braunr> i'm doing it now :) ### IRC, freenode, #hurd, 2013-10-02 - <braunr> i've traced the problem up to truncate - <braunr> which gets a negative size - <braunr> shouldn't take long to find out where it comes from now - <pinotree> it seems our truncate doesn't handle negative values well though - <braunr> EINVAL The argument length is negative or larger than the - maximum file size. - <braunr> i still have to see whether it comes from the user (unlikely) or - if it's an internal inconsistency - <braunr> i suspect some code wrongly handles vm_map failures - <braunr> leading to that inconsistency - <braunr> pinotree: looks like glibc doesn't check for length >= 0 - <pinotree> yeah - <braunr> servers should do it nonetheless - <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both? - <braunr> it appears a client does the truncate - <braunr> i'd say both - <braunr> can you take the glibc part ? :) - <pinotree> i was going to do the hurd part... :p - <pinotree> ok, i'll pick libc - <braunr> well i'm doing it already - <braunr> i want to write a test case first - <braunr> to make sure that's the problem - <pinotree> already on the hurd part, you mean? - <braunr> yes - <pinotree> ok - <braunr> ok looks like it - <pinotree> would you share the test you are doing, so i don't need to write - it again? :) - * pinotree lazy - <braunr> :) - <braunr> as soon as darnassus is restarted - <pinotree> ideally we could have some repository with all the testcases - written over time to fix bugs in implementations/compatibility/etc - <braunr> i noticed the system doesn't automatically reboot when e2fsck says - reboot, and no unexpected inconsistency was found - <braunr> is that normal ? - <pinotree> or having something like posixtestsuite, but actively maintained - <braunr> pinotree: polishing the test before sending it - <pinotree> sure, no hurry :) - <braunr> i can't reproduce the assertion but it does make ext2fs freeze - <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c - <pinotree> merci - <braunr> pinotree: ustr builds - <pinotree> wow - <braunr> the client code (ustr) seems to perform a ftruncate with size - ((size_t)-1) whereas lengths are signed .. - <braunr> i'll check other libraries and send a patch soon - <teythoon_> braunr: btw, did you fix the leak? <braunr> yes <braunr> @@ -2331,22 +2263,18 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. had my development vm running on that patches for two weeks -### IRC, freenode, #hurd, 2013-10-03 +### IRC, freenode, #hurd, 2013-10-02 - <braunr> youpi: i've committed a fix to hurd that checks for negative sizes - when truncating files - <braunr> this allows building the ustr package without making ext2fs choke - on an assertion - <braunr> pinotree is preparing a patch for glibc - <braunr> see truncate/ftruncate - <braunr> with an off_t size parameter, which can be negative - <braunr> EINVAL The argument length is negative or larger than the - maximum file size. - <braunr> hurd servers were not conforming to that before my change + <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a + translator + <braunr> i'll fix it too ## Multiple mtab Translators Spawned +Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? + + ### IRC, freenode, #hurd, 2013-09-20 <braunr> teythoon: how come i see three mtab translators running ? @@ -2365,25 +2293,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. [[open_issues/libnetfs_passive_translators]]. -### IRC, freenode, #hurd, 2013-09-26 - - <braunr> teythoon: hum, i just saw something disturbing - <braunr> teythoon: to isolate the leak, i created my own proc directory - <braunr> and the mtab translators it spawns seem to be owned by root oO - <teythoon> braunr: but how is that possible? are you sure? have you checked - with 'ids'? - <braunr> no i'm not sure - <braunr> also, ext2fs seems to ignore --writable when started as a passive - translator - <braunr> < teythoon> braunr: but how is that possible? - <braunr> messup with passive translators i guess - <braunr> teythoon: actually, it looks like it has effective/available id - <braunr> it has no* - <braunr> this feature doesn't map well in unix - <teythoon> braunr: ah yes, htop doesn't handle this well and shows root - indeed, our ps shows - as username - <braunr> yes - ### [[!debbug 724868]] @@ -2449,12 +2358,18 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> while procfs doesn't <braunr> teythoon: ok, looks like i have a working patch that merely caches the node for mounts - <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a - translator - <braunr> i'll fix it too <braunr> i installed my fixed procfs on darnassus, only one mtab :) <teythoon> nice :) + + <braunr> i have a fix for the multiple mtab issue, will send a patch + tonight + + +## `/home` Missing + +### IRC, freenode, #hurd, 2013-10-04 + <braunr> now, why is there no /home in df output ? <teythoon> not sure <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive @@ -2491,9 +2406,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. although it's very rare and not hard to solve) <teythoon> a weird beaving translator then :) - <braunr> i have a fix for the multiple mtab issue, will send a patch - tonight - <braunr> teythoon: if ext2fs is set active, mtab output reports it <braunr> teythoon: looks like this bug is what allows mtab not to deadlock @@ -2501,11 +2413,8 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <braunr> teythoon: if (control && control->pi.port_right == fsys) <braunr> that's the filtering i was previously talking about - <braunr> oh please don't name global variables "path" ... - <braunr> youpi: i fixed procfs on ironforge and exodar to be started as - procfs -c -k 3 - <braunr> without -k 3, many things as simple as top and uptime won't work + <braunr> oh please don't name global variables "path" ... ### IRC, freenode, #hurd, 2013-10-06 @@ -2881,7 +2790,7 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks proc -[[libpthread_set_stack_size]]. +[[open_issues/libpthread_set_stack_size]]. <braunr> teythoon: but anyway, it does look like your patches are actually fine diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index 39840e99..924abc99 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -67,30 +67,6 @@ It is stated by `/hurd/init`. ## IRC, freenode, #hurd, 2013-09-25 <braunr> so nice to finally see proc in top :) - <braunr> hm cute, htop layout has become buggy, top just won't start - <teythoon> braunr: make sure your procfs knows the correct kernel pid - <teythoon> # showtrans /proc - <teythoon> /hurd/procfs -c -k 3 - <teythoon> we could have handled this nicer if procfs were integrated - upstream - <teythoon> we should probably just update the default - <braunr> teythoon: mhm - <braunr> $ fsysopts /proc - <braunr> /hurd/procfs --stat-mode=444 --fake-self=1 - <braunr> $ showtrans /proc - <braunr> /hurd/procfs -c - <pinotree> -c == --stat-mode=444 --fake-self=1 - <braunr> better indeed - <braunr> teythoon: thanks - - -## IRC, freenode, #hurd, 2013-10-24 - - <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop - anymore, all zeroes, confirmed? - <braunr> gg0: no - <braunr> gg0: you probably need to reset procfs - <braunr> gg0: settrans /proc /hurd/procfs -c -k 3 # Process Discovery diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 8ac48a59..54de54c2 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -599,3 +599,40 @@ Needed by glibc's `pldd` tool (commit enough <braunr> it probably is <braunr> settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + <braunr> hm cute, htop layout has become buggy, top just won't start + <teythoon> braunr: make sure your procfs knows the correct kernel pid + <teythoon> # showtrans /proc + <teythoon> /hurd/procfs -c -k 3 + <teythoon> we could have handled this nicer if procfs were integrated + upstream + <teythoon> we should probably just update the default + <braunr> teythoon: mhm + <braunr> $ fsysopts /proc + <braunr> /hurd/procfs --stat-mode=444 --fake-self=1 + <braunr> $ showtrans /proc + <braunr> /hurd/procfs -c + <pinotree> -c == --stat-mode=444 --fake-self=1 + <braunr> better indeed + <braunr> teythoon: thanks + + +## IRC, freenode, #hurd, 2013-10-04 + + <braunr> youpi: i fixed procfs on ironforge and exodar to be started as + procfs -c -k 3 + <braunr> without -k 3, many things as simple as top and uptime won't work + + +## IRC, freenode, #hurd, 2013-10-24 + + <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop + anymore, all zeroes, confirmed? + <braunr> gg0: no + <braunr> gg0: you probably need to reset procfs + <braunr> gg0: settrans /proc /hurd/procfs -c -k 3 diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn index 5ae52abe..834ef9bd 100644 --- a/hurd/translator/term.mdwn +++ b/hurd/translator/term.mdwn @@ -24,6 +24,10 @@ The *term* translator implements POSIX termios discipline. <braunr> good news <braunr> the terminal leak is related to privilege separation + +[[tschwinge]] confirming (using `ssh -t [machine] tty`) that with privilege +separation enabled there is this problem, and once disabled it goes away. + <atheia> I love how, as an unknowing by-stander, that is somehow good news :-) <braunr> :) @@ -38,6 +42,9 @@ The *term* translator implements POSIX termios discipline. <atheia> ah, yes, both definitely good news. Congrats on the progress. <braunr> i remember we used to disable privilege separation in the past <braunr> i'll have to dig what made us use it + +[[news/2010-09]]. + <braunr> interesting, screen seems to be affected nonetheless <braunr> so it's something common to both screen and ssh privsep <braunr> apparently, what sshd+privse and screen have in common is a fifo diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index d79fa337..9b330507 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -3127,7 +3127,7 @@ In context of [[hurd/libports]], *Open Issues*, *IRC, freenode, #hurd, ## IRC, freenode, #hurd, 2014-01-20 -[[translate_fd_or_port_to_file_name]]: +[[open_issues/translate_fd_or_port_to_file_name]]: <teythoon> i wonder if it would not be best to add a description to mach tasks diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn index 799ed5cc..b20f1fe0 100644 --- a/microkernel/mach/message/msgh_id.mdwn +++ b/microkernel/mach/message/msgh_id.mdwn @@ -15,6 +15,8 @@ files. [[!toc]] +See also [[open_issues/versioning]]. + # IRC, freenode, #hurd, 2012-07-12 diff --git a/news/2011-q2.mdwn b/news/2011-q2.mdwn index 9d679f44..1c677670 100644 --- a/news/2011-q2.mdwn +++ b/news/2011-q2.mdwn @@ -94,7 +94,7 @@ lwn: netzwelt: - *[Debian 7.0 Wheezy: Erste Pläne für Hurd statt Linux-Kernel + "*[Debian 7.0 Wheezy: Erste Pläne für Hurd statt Linux-Kernel \[de\]](http://www.netzwelt.de/news/87551-debian-7-0-wheezy-erste-plaene-hurd-statt-linux-kernel.html)*, Netzwelt, Markus Franz, 2011-07-15" diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn index 8d18d1e2..e72b59d3 100644 --- a/open_issues/glibc.mdwn +++ b/open_issues/glibc.mdwn @@ -18,6 +18,8 @@ Here's what's to be done for maintaining glibc. # [[General information|/glibc]] + * [[Versioning]] + # [[Sources|source_repositories/glibc]] @@ -2404,6 +2406,70 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 type for some flock structure field) <youpi> s/by/be/ + * `truncate`/`ftruncate` + + Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603, + glibc still to be done? + + IRC, freenode, #hurd, 2013-10-01: + + <pinotree> libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ← + this one? + <pinotree> iirc you constantly get that when building ustr + <braunr> is ustr a package ? + <pinotree> yes + <pinotree> iirc the ustr tests are mostly disk-intensive + + IRC, freenode, #hurd, 2013-10-02: + + <braunr> i've traced the problem up to truncate + <braunr> which gets a negative size + <braunr> shouldn't take long to find out where it comes from now + <pinotree> it seems our truncate doesn't handle negative values well though + <braunr> EINVAL The argument length is negative or larger than the + maximum file size. + <braunr> i still have to see whether it comes from the user (unlikely) or + if it's an internal inconsistency + <braunr> i suspect some code wrongly handles vm_map failures + <braunr> leading to that inconsistency + <braunr> pinotree: looks like glibc doesn't check for length >= 0 + <pinotree> yeah + <braunr> servers should do it nonetheless + <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both? + <braunr> it appears a client does the truncate + <braunr> i'd say both + <braunr> can you take the glibc part ? :) + <pinotree> i was going to do the hurd part... :p + <pinotree> ok, i'll pick libc + <braunr> well i'm doing it already + <braunr> i want to write a test case first + <braunr> to make sure that's the problem + <pinotree> already on the hurd part, you mean? + <braunr> yes + <pinotree> ok + <braunr> ok looks like it + <braunr> i can't reproduce the assertion but it does make ext2fs freeze + <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c + <pinotree> merci + <braunr> pinotree: ustr builds + <pinotree> wow + <braunr> the client code (ustr) seems to perform a ftruncate with size + ((size_t)-1) whereas lengths are signed .. + <braunr> i'll check other libraries and send a patch soon + + IRC, freenode, #hurd, 2013-10-03: + + <braunr> youpi: i've committed a fix to hurd that checks for negative sizes + when truncating files + <braunr> this allows building the ustr package without making ext2fs choke + on an assertion + <braunr> pinotree is preparing a patch for glibc + <braunr> see truncate/ftruncate + <braunr> with an off_t size parameter, which can be negative + <braunr> EINVAL The argument length is negative or larger than the + maximum file size. + <braunr> hurd servers were not conforming to that before my change + * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE` * <https://sourceware.org/glibc/wiki/PointerEncryption> @@ -2699,7 +2765,7 @@ Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852 transition to the latter file, continuing to accept the former values as deprecated for some time? * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler - optimization` -- have to revert, see [[sourceware_PR 15605]]. For + optimization` -- have to revert, see [[!sourceware_PR 15605]]. For analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49. * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions for Linux and glibc` -- alright for us? diff --git a/open_issues/glibc/t/tls.mdwn b/open_issues/glibc/t/tls.mdwn index eba2b88b..b10703fd 100644 --- a/open_issues/glibc/t/tls.mdwn +++ b/open_issues/glibc/t/tls.mdwn @@ -71,7 +71,7 @@ After commit a9538892adfbb9f092e0bb14ff3a1703973968af, it's <youpi> have you had a look at the tls.pdf from Uli ? <youpi> all the gory details are there :) -Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[sourceware_PR 15754]], adds +Commit c61b4d41c9647a54a329aa021341c0eb032b793e, [[!sourceware_PR 15754]], adds `sysdeps/i386/stackguard-macros.h:POINTER_CHK_GUARD`, which is not correct for us (at the moment), but it also shouldn't cause any harm, as this file is only used in `elf/tst-ptrguard1.c` and `elf/tst-stackguard1.c`, which now will fail diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/versioning.mdwn index 33ef8f3a..1987b6ca 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/versioning.mdwn @@ -9,17 +9,52 @@ 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]]."]]"""]] -[[!tag open_issue_glibc open_issue_libpthread]] +Things to consider regarding *versioning*. + +The provider and user of any interface need to agree about how to interpret the +data being exchanged. Internal-only interfaces can be changed easily, because +you can change the provider and user at the same time. Interfaces that are +exposed externally require more attention, for obvious reasons. To *change* +interfaces means to either remove, or add, or modify an existing interface. +Modify basically means to remove and then re-add a variant, re-using the former +name/identifier. + +[[!toc]] + + +# [[RPC]]s + +## [[microkernel/mach/message/msgh_id]] + + +# Shared Libraries -Things to consider doing when bumping the glibc SONAME. + * [[!wikipedia soname]] + * ELF symbol versioning + * [[!wikipedia "GNU Libtool"]] + + +## Hurd + +Transition to "normal" ELF symbol versioning/libtool? + +For all libraries, the SONAME is currently set to *0.3*. [[!message-id +desc="Not changed" "87ob7cxbu6.fsf@kepler.schwinge.homeip.net"]] when doing the +[[Hurd 0.5 release|news/2013-09-27]]. + + +## glibc + +Bump the glibc SONAME to some point, or can do everything with symbol +versioning? There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` -[[!toc]] +### IRC, freenode, #hurd, 2012-12-14 -# IRC, freenode, #hurd, 2012-12-14 +[[!tag open_issue_glibc open_issue_libpthread]] In context of [[packaging_libpthread]]/[[libpthread]]. @@ -38,9 +73,9 @@ In context of [[packaging_libpthread]]/[[libpthread]]. "4BFA500A.7030502@gmail.com"]]. -# `time_t` -- Unix Epoch vs. 2038 +### `time_t` -- Unix Epoch vs. 2038 -## IRC, freenode, #hurd, 2013-12-12 +#### IRC, freenode, #hurd, 2013-12-12 <azeem> because it gets discussed in #debian-devel for the Linux i386 architecture right now: what's the deal with hurd-i386 and the 32bit |