<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.os.haiku.devel">
    <title>gmane.os.haiku.devel</title>
    <link>http://blog.gmane.org/gmane.os.haiku.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24221"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24213"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24190"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24183"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24182"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24179"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24171"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24170"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24165"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24164"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24151"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24150"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24137"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24129"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24125"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24124"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24113"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24105"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24098"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.os.haiku.devel/24096"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24221">
    <title>RFC: Packages and the Deskbar menu</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24221</link>
    <description>&lt;pre&gt;Greetings,

I'm currently in the process of extending the package file format to 
provide additional meta information, like what settings files the 
package provides/creates, what Unix users/groups it requires, etc. One 
of the things I considered adding are information regarding the Deskbar 
menu items the package would like to add. When installing a package the 
package manager would then ask the user whether they should actually be 
created.

However, talking to Stippi, he convinced that a simpler, automated 
approach makes a lot more sense. The basic idea is that the Deskbar menu 
merges an auto-generated part -- that is all the entries provided by 
installed packages -- with whatever the user has added manually in 
~/config/settings/deskbar/menu/. The assumption is that most users will 
be happy with installed applications appearing automatically in their 
Deskbar menu -- particularly when reasonable categories are provided. 
For puristic users a Deskbar setting to disable the auto-generated part 
could&lt;/pre&gt;</description>
    <dc:creator>Ingo Weinhold</dc:creator>
    <dc:date>2013-05-20T20:28:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24213">
    <title>AW: [haiku-development] Re: What to do withtermcap? Scene II.</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24213</link>
    <description>&lt;pre&gt;Hi,

switch to some of my other unfinished projects like USB audio or like it. So, sorry. ;-)

For everything I'm doing in the Terminal, it works perfectly. I do however have some unsupported USB Audio hardware, so I would be all for that! :-)

Best regards,
-Stephan


&lt;/pre&gt;</description>
    <dc:creator>superstippi&lt; at &gt;gmx.de</dc:creator>
    <dc:date>2013-05-18T12:19:03</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24190">
    <title>File Open/Save Dialog Edit menu</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24190</link>
    <description>&lt;pre&gt;I recently noticed that the cut copy and paste menu items are found under the File menu in the Open/Save dialogs. Would anyone object to me moving those items to a new Edit menu?

John Scipione

&lt;/pre&gt;</description>
    <dc:creator>John Scipione</dc:creator>
    <dc:date>2013-05-14T16:15:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24183">
    <title>the state of the system ?</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24183</link>
    <description>&lt;pre&gt;I haven't been following development closely much lately, so I was 
wondering if anyone knows what the state of the system is these days ? I 
peeked into cgit and it looks like things have been busy, but where does 
the project sit ? package management ? beta status ?


Sean


&lt;/pre&gt;</description>
    <dc:creator>Sean Collins</dc:creator>
    <dc:date>2013-05-13T03:14:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24182">
    <title>How to add file names to a catalog at build time?</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24182</link>
    <description>&lt;pre&gt;I am trying to internationalize the keymap names and keyboard layout
names that appear in the Keymap preflet. In order to do that I need to
add the keymap and layout file names to Keymap's catalog.

I'd prefer that the catalog entries were auto-generated from the file
names so that we don't have to maintain a separate list. That means
building a header file at compile time that contains the names and
then including it in the Keymap preflet's Jamfile.

What I'm thinking of is a header file that has a bunch of
B_TRANSLATE_MARK("&amp;lt;keymap_name&amp;gt;"); entries and then in Keymap I issue
B_TRANSLATE_NOCOLLECT("&amp;lt;keymap_name&amp;gt;") to get the localized name out
of the catalog.

I've created the list manually by just filling out the keymap names
which seems to work, but, like I said, I'd prefer to fill out the
catalog from the file names at compile time directly.

We are already looping through the list of keymaps and keyboard
layouts in HaikuImage to add the files to the image, would it be
possible to use Jam to build a head&lt;/pre&gt;</description>
    <dc:creator>John Scipione</dc:creator>
    <dc:date>2013-05-13T01:22:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24179">
    <title>GCC 4.7 update</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24179</link>
    <description>&lt;pre&gt;Hi,

I plan to update gcc to 4.7.3 on trunk by the end of the week.
Tests don't show any regression, though I only tested on emulation x86 and
x86_64.

Any objections?

Bye,
Jérôme
&lt;/pre&gt;</description>
    <dc:creator>Jérôme Duval</dc:creator>
    <dc:date>2013-05-10T20:54:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24171">
    <title>Haiku development: getting involved</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24171</link>
    <description>&lt;pre&gt;Hi all.

My name is Vladimir Kovalev, I'm from Russia (Moscow). I'm a professional
C/C++ developer with 5+ years of experience. I have a bachelor's degree at
Applied maths and computer science and master's degree (Moscow State
University) also at Applied Maths and Computer Science.

With deep knowledge of C/C++ (including new C++11 standard), STL, Boost and
other libraries I want to help the haiku community to develop Haiku OS.

Mostly I write system software, networking software and services (including
high-load projects). I also have experience in writing device drivers and
kernel modules for Linux OS and in many other fields (GUI with GTK, Qt,
wxWidgets), multimedia and cryptography libraries, system software written
in assembly language (intel and at&amp;amp;t syntax) and so on.

I've already familiarized with haiku source code and build system (under
Fedora Linux, unfortunately without xattr support because of my ext4
partitions). So I'm opened to any suggestions about what tasks can I
perform. I've already vie&lt;/pre&gt;</description>
    <dc:creator>Vladimir Kovalev</dc:creator>
    <dc:date>2013-05-08T19:36:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24170">
    <title>quit/kill Team Monitor</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24170</link>
    <description>&lt;pre&gt;Hi,
in these days i've recompiled "Lock Workstation": an app which
provides a login mask to lock Haiku boxes with a password (and i've
also made a modern login mask, only using the  magnificient
WonderBrush) :-)
Screenshot: http://s22.postimg.org/42zuiooy9/Lock_Workstation_Haiku.jpg

For security reason, when LockWorkstation is activated, mouse click is
disabled and also Team Monitor *should* be disabled, but CTRL ALT CANC
when LockWorkstation is activate, will bring Team Monitor window, with
the ability to kill (and so bypass) the login mask.

This is the part of code which should skip/quit Team Monitor:

BString strSignature;
message-&amp;gt;FindString("be:signature", &amp;amp;strSignature);
if (strSignature.ICompare ("application/x-vnd.Be-input_server") == 0)
{
app_info info;
be_roster-&amp;gt;GetAppInfo (strSignature.String(), &amp;amp;info);
BMessage msgGetProperty, msgSetProperty, msgReply;
status_t result;
msgGetProperty.what = B_GET_PROPERTY;
msgGetProperty.AddSpecifier("Messenger");
msgGetProperty.AddSpecifier("Window", "Team Mo&lt;/pre&gt;</description>
    <dc:creator>Giovanni Mugnai</dc:creator>
    <dc:date>2013-05-08T12:52:26</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24165">
    <title>Mediaplayer use of BList to store indices</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24165</link>
    <description>&lt;pre&gt;Hi,

I went ahead with some 64 bit fixes in MediaPlayer and got stuck with this:

src/apps/mediaplayer/playlist/ListViews.cpp: In member function 'virtual
void DragSortableListView::MessageReceived(BMessage*)':
src/apps/mediaplayer/playlist/ListViews.cpp:331:28: error: cast to pointer
from integer of different size [-Werror=int-to-pointer-cast]

The code tries to add an int32 in a BList:
indices.AddItem((void*)index);

Any opinions on how to fix this?

Bye,
Jérôme
&lt;/pre&gt;</description>
    <dc:creator>Jérôme Duval</dc:creator>
    <dc:date>2013-05-04T09:22:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24164">
    <title>B_PRIdBIGTIME and B_PRIiBIGTIME macros</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24164</link>
    <description>&lt;pre&gt;Hi,

is it OK to add these macros in SupportDefs.h?

/* bigtime_t */
#define B_PRIdBIGTIME    B_PRId64
#define B_PRIiBIGTIME    B_PRIi64

Bye,
Jerome
&lt;/pre&gt;</description>
    <dc:creator>Jérôme Duval</dc:creator>
    <dc:date>2013-05-04T08:08:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24151">
    <title>BAboutWindow lifecycle</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24151</link>
    <description>&lt;pre&gt;Hello devs,

I have a problem with the way our BAboutWindow currently behaves. The idea 
of the current code is that you create the window on the first call to
App::AboutRequested and show it. Instead of closing, the window is hidden, 
so that subsequent calls just show it again.

To do this, the BAboutWindow code overrides QuitRequested to hide the 
window and return false (that stops the quitting process). An annoying side 
effect is that Application::QuitRequested will not quit the app if a window 
returns false from this method.

Moreover, having the window hidden means its BLooper keeps running. This 
sounds like wasting more resources that recreating the window if it is 
needed again (an unlikely event, you don't usually look at an about window 
multiple times). It also is nonstandard behavior, and a trap for the 
unsuspecting developers using the class.

This can easily be fixed by letting the window close. Callers in our source 
tree can be adjusted to always recreate it. There is a regression in doi&lt;/pre&gt;</description>
    <dc:creator>pulkomandy-cGbilrz/ASCq8YCFLG48yw&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-04-29T17:55:37</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24150">
    <title>Working on rolling some Haiku code into Mesa3D</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24150</link>
    <description>&lt;pre&gt;I've finally pinned down some code that can transition into the Mesa3D 
/ Gallium3D projects for Haiku.
My plan at the moment is to try and move the winsys code and some of 
the GL screen initialization code into Mesa.

If you have entirely too much time on your hands you can see my 
progress on the Mesa code here:
https://github.com/kallisti5/mesa-haiku

The plans I have at the moment would mean that the following code would 
be 100% absorbed into Mesa:
http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl/swpipe/bitmap_wrapper.cpp
http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl/swpipe/SoftwareWinsys.cpp

And the following file would see reductions in code and rely on 
functions within Mesa:
http://cgit.haiku-os.org/haiku/tree/src/add-ons/opengl/swpipe/GalliumContext.cpp


I've reached out to Artur to ask to re-license under the Mesa "as-is" 
license.

Mainline Mesa + Haiku won't see any commits until i've proven that the 
changes work.

  -- Alex


&lt;/pre&gt;</description>
    <dc:creator>Alexander von Gluck IV</dc:creator>
    <dc:date>2013-04-29T07:09:54</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24137">
    <title>RFC: Package management and handling of settings files</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24137</link>
    <description>&lt;pre&gt;Greetings,

I'd like to gather a few opinions and ideas wrt. how we want to handle 
settings (and similar) files in a package management context. Mainly 
this is about what shall happen with a software's settings files when 
said software is installed/uninstalled/updated.

There are a few different kinds of settings files, which may need 
different handling:

1. Highly compatible settings

Common for native applications. The application can load settings files 
written by an older (or newer) version. The settings file may be 
completely optional or a default settings file must or is recommended to 
be installed.

Handling:
- Installation/update: No-op, if the software doesn't come with a
   default to be installed or there already is a settings file
   installed. Otherwise install the default.
- Deinstallation: Remove settings file, if desired by the user
   (maybe back up first).

2. Potentially incompatible settings

Not unheard of in ported software. Some kind of configuration file is 
required and the fo&lt;/pre&gt;</description>
    <dc:creator>Ingo Weinhold</dc:creator>
    <dc:date>2013-04-23T15:01:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24129">
    <title>Commit message subject line</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24129</link>
    <description>&lt;pre&gt;I've noticed that sometimes emails to haiku-commits will come looking
like replies to the previous push instead of as a new email thread.
I've discovered that this is because the new email affects identical
components as the previous email which means that it also has an
identical subject. For example this just happened with Ingo's few
recent pushes concerning package management.

Would it be possible to add some sort of unique identifier such as the
short hash of the last commit to the email subject so that each email
will be treated as a new thread? It's a small detail I know, but, it
would make reading commits slightly easier for me.

Thanks for your consideration,
John Scipione


&lt;/pre&gt;</description>
    <dc:creator>John Scipione</dc:creator>
    <dc:date>2013-04-22T20:34:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24125">
    <title>Greek Extended Keymap - Greek Polytonic</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24125</link>
    <description>&lt;pre&gt;
Greek Extended Keymap - Greek Polytonic


Hello!

I need help. Before time I began my own project for Haiku in order to 
supports Greek Polytonic keyboard. The project is finished, and soon 
I’ll upload the source code, also I prepare a video for youtube.

The code works very well so I can write in Haiku Greek Polytonic using 
32 dead keys.

But I have a small problem.

For the dead key Rough breathing (Dasia), I have 18 entries, and I can 
see them in Keymap (Preferences) and I can write 18 symbols for the dead 
key Rough breathing (Dasia) in StyleEdit and in other programs.

http://en.wikipedia.org/wiki/Greek_diacritics

http://en.wikipedia.org/wiki/Rough_breathing

But when I run the following command in Terminal,

Keymap - d “Greek Extended” &amp;gt; mydumpfile

and then I open the text file mydumpfile with the program StyleEdit, I 
see for the dead key Rough breathing (Dasia)that it has 16 entries 
instead of 18.


I don’t know who is the counter (or counters) in order to increase price 
from 16 to 18&lt;/pre&gt;</description>
    <dc:creator>ΧΡΗΣΤΟΣ ΜΑΡΕΤΣΙΚΟΣ</dc:creator>
    <dc:date>2013-04-22T11:49:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24124">
    <title>The Terminal: MuTerm rudiments for multi-byte character sets designation. To drop or not to drop?</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24124</link>
    <description>&lt;pre&gt;Dear Colleagues,

during trying to resolve a Trac issue #6227, related to support of 
Chinese GB18030 encoding I have found some code that is looking like 
dead or semi-functional. I'm speaking about support of so known 
designation of 96/94 multi-byte characters sets, mentioned in in Ecma-35 
as GZDM4, G1ZDM4, G2ZDM4, G2ZDM4 and G1ZDM6, G2ZDM6, G2ZDM6 commands. 
Looks like original MuTerm 2.3 from which we have started our Terminal 
development had some rudimentary support of such functionality for 
Japanese encoding. From the other side this functionality is not related 
to current support of charsets conversion in the Terminal and can be 
dropped without any affect on it. Another issue with this designation 
functionality that it uses only single-shift functions SS2 and SS3 to 
designate alternative encoding but not the whole charset designations. 
That looking suspicious for me and I have a big desire either to bring 
it part in order or drop this functionality. The question is: Is this 
multi-byte desig&lt;/pre&gt;</description>
    <dc:creator>Siarzhuk Zharski</dc:creator>
    <dc:date>2013-04-18T07:12:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24113">
    <title>Haiku Technical Writer wanted</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24113</link>
    <description>&lt;pre&gt;Good morning. I am the Assistant Systems Admin, Assistant Editor and
Staff Writer for Unixmen.com. We are a computer and technical based
website which publishes Unix and Linux related content. We have
increased our web presence over the past 12 months to a point where we
and are currently seeking the assistance of new freelance technical
writers. We are seeking specifically someone who has the time to
contribute to the website and write about Haiku.

It would be a chance for the writer to freely express their views and
opinions on Haiku and also increase media exposure for the Haiku project.

There is no specific skill set required other than good English skills
and the ability to write regular articles which contain decent and
understandable content.

I look forward to hearing from a few of you soon. For more information
or to express your interest, please email me at chrisjones-3rqk3KfgR8VBDgjK7y7TUQ&amp;lt; at &amp;gt;public.gmane.org


Regards

Chris Jones
Staff Writer, Assistant Site Editor
and Assistant Systems Administr&lt;/pre&gt;</description>
    <dc:creator>Chris Jones c/o Unixmen</dc:creator>
    <dc:date>2013-04-09T23:05:58</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24105">
    <title>Fwd: [haiku-bugs] Re: [Haiku] #9636: Error opening terminal: xterm-256color</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24105</link>
    <description>&lt;pre&gt;Hi All,

I repost it here, just to explain about reasons of my decision to wide 
audience.

#9636: Error opening terminal: xterm-256color
-------------------------------------+----------------------------
    Reporter:  humdinger              |      Owner:  siarzhuk
        Type:  bug                    |     Status:  closed
    Priority:  normal                 |  Milestone:  R1
   Component:  Applications/Terminal  |    Version:  R1/Development
  Resolution:  no change required     |   Keywords:  xterm, nano
  Blocked By:                         |   Blocking:
Has a Patch:  0                      |   Platform:  All
-------------------------------------+----------------------------
Ticket URL: &amp;lt;http://dev.haiku-os.org/ticket/9636#comment:4&amp;gt;

Comment (by siarzhuk):

  Replying to [comment:3 bonefish]:
  &amp;gt; TBH, I don't understand why we're setting `TERM` to 
"xterm-256color".

  Because "xterm" has Co (color count) set to 8. So to let the newest
  versions of console apps (text editors for example) profit from&lt;/pre&gt;</description>
    <dc:creator>Siarzhuk Zharski</dc:creator>
    <dc:date>2013-04-08T06:43:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24098">
    <title>BNetworkInterface weirdness</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24098</link>
    <description>&lt;pre&gt;Is it correct that BNetworkInterfaceAddress::Broadcast() and
::Destination() both return the broadcast address ?
I thought Destination() would return the gateway for that interface... and
anyway, how do I get the default route of a given interface ?
&lt;/pre&gt;</description>
    <dc:creator>Stefano Ceccherini</dc:creator>
    <dc:date>2013-04-06T17:33:33</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24096">
    <title>Enabling TRACE output?</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24096</link>
    <description>&lt;pre&gt;Sorry, I'm newbie floundering again (:-()

I want to figure out why one of my USB game controllers (Strategic
Commander) works fine in Linux but is not recognised by Haiku.
 Another -- a ThrustMaster -- is perfect on both platforms.
Their listusb output is virtually identical.

I'm assuming that if I get the 'TRACE' statements in the usb_hid
sources enabled, I'll see diagnostics in syslog, but how do I do that?
I thought maybe doing a 'jam -sDEBUG=1 -q' would do it, and it
generated a much bigger file, but there's no new output in syslog.
(I tried -sDEBUG=9 and it started to compile the whole of Haiku
into the usb_hid source dir!)

Help. please?

Thanks,
-- Pete --


&lt;/pre&gt;</description>
    <dc:creator>Pete Goodeve</dc:creator>
    <dc:date>2013-04-05T01:38:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.os.haiku.devel/24077">
    <title>GIT help</title>
    <link>http://comments.gmane.org/gmane.os.haiku.devel/24077</link>
    <description>&lt;pre&gt;Seems I can't get anything right round here... (:-()

I revised the patchbay directory in my GIT tree, and reached the point
where I decided to make a 'git diff patchbay'.  When I looked at it,
though, I realized that I had added an rdef file to the directory
(as well as deleting a couple of obsolete ones), so I did a 'git add .'
and tried again.

Now the diff file (which overwrote the nearly good one) contains
*only* the rdef addition and the deletions.  All the essential stuff
has gone!

Before I screw things up further, can someone suggest how I
can rectify things?  (I only did the add, no commit or anything.)

Thanks,
-- Pete --


&lt;/pre&gt;</description>
    <dc:creator>Pete Goodeve</dc:creator>
    <dc:date>2013-04-01T21:31:26</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.haiku.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.haiku.devel</link>
  </textinput>
</rdf:RDF>
