GNUmoon has quit [Write error: Connection reset by peer]
prabhakarlad has quit [Quit: Ping timeout (120 seconds)]
neuberfran has quit [Quit: Ping timeout (120 seconds)]
xmn has quit [Ping timeout: 240 seconds]
xmn has joined #yocto
osama4 has quit [Ping timeout: 272 seconds]
florian_kc has quit [Ping timeout: 240 seconds]
prabhakarlad has joined #yocto
otavio has quit [Remote host closed the connection]
sakoman has joined #yocto
yolo has joined #yocto
<yolo>
in the newest bitbake hello example, it runs 'bitbake' in a blank folder and saying some mistakes, I ran it, no errors, no warning about BBPATH unset, what am I missing
<yolo>
there is a bitbake-cookerdaemon.log generated, inside there is no warning or error either, is the newest doc out of date
<yolo>
yes the doc is unclear, BBPATH is not needed until you build out of topdir
camus has joined #yocto
GNUmoon has joined #yocto
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #yocto
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #yocto
<vmeson>
yolo: can you provide more context? Are you using poky.git/master or jsut bitbake and what steps are required to encounter the error you see. Did things work before? Did you try to revert?
<yolo>
I did: git clone bitbake; set PATH for bitbake; mkdir hello; cd hello; bitbake; that's all, no errors reported, but the doc says it should report errors. I eventually got the bitbake hellworld working fine. BBPATH is optional(i.e. no error) as long as you stay inside the project
<vmeson>
yolo: ah, yes, I just scrolled back and saw that: 13:16] <yolo> git clone bitbake
<yolo>
is devtool a standalone project or just part of poky or something?
<yolo>
plan to restudy bitbake, then oe-core, then openembedded, then poky/yocto before I got lost
<yolo>
also is toaster mature enough for 'product use'? last time I used yocto toaster just came out :) so I never actually used it
<vmeson>
yolo: devtool is part of YP / oe-core
<vmeson>
toaster is having a mid-life crisis or something. ;-) It's been around for a while, a few people use it. We were talking about it's future on this week's conference call.
<vmeson>
I think it was broken until RP pushed a bitbake fix: bf723f2c 2022-03-07 server/xmlrpcserver: Add missing xmlrpcclient import
<vmeson>
yolo: if you see any problems with devtool or toaster or just have comments or questions, we're all ears. Doubly so for patches, in which casse we're all hands...
<yolo>
thanks! it has been a while, does yocto/oe-core have a menuconfig like buildroot and the others
<vmeson>
yolo: cmdline, no there's no menuconfig. Toaster is supposed to be a good way to discover features . I just read / search all the commits, code!
<yolo>
thanks again, so the way to use it is unchanged over the years then.
<vmeson>
yolo: there have been some recent syntax changes on overrides : _ -> : and some inclusive language changes but yeah, it's basically the same.
* vmeson
wanders off for the night...
GNUmoon has quit [Remote host closed the connection]
jclsn78 has joined #yocto
GNUmoon has joined #yocto
jclsn7 has quit [Ping timeout: 252 seconds]
<yolo>
oe-core defaults to ipk(was it rpm?), qemu has no riscv support yet? and local.conf has no parallel build settings I assume bitbake will build in parallel on its own then?
xmn has quit [Ping timeout: 256 seconds]
<yolo>
http://www.openembedded.org/wiki/OE-Core_Standalone_Setup seems broken for me: bitbake core-image-minimal, I got : ERROR: Variable PROVIDES_prepend contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake.
camus has quit [Read error: Connection reset by peer]
camus has joined #yocto
<yolo>
found the riscv meta layer that hopefully contains qemu-riscv
<yolo>
question: is musl an officially supported lib in yocto? like what buildroot|opewnrt|alpine does, or it's just an add-on that "you're on your own"
<jclsn78>
rburton: Yeah so I created a man page, but it is just one big file containing the information. Like this it is not of much use...
dev1990 has joined #yocto
<LetoThe2nd>
yo dudX!
<LetoThe2nd>
quick one - is there some part in the documentation that explains (and shows best practises) for custom commercial licenses? LICENSE="CLOSED" is the usual, but wrong way as we all know.
<mckoan>
LetoThe2nd: hey
<LetoThe2nd>
mckoan: howdy!
florian_kc has joined #yocto
goliath has joined #yocto
florian_kc has quit [Ping timeout: 240 seconds]
mvlad has joined #yocto
risca has quit [Remote host closed the connection]
<qschulz>
LetoThe2nd: HOWEVER, if multiple of your pieces of software have the same license, it'd probably be better to add this license file to the list of valid licenses
<qschulz>
LetoThe2nd: you still need the LICENSE_FLAGS though (I didn't need it technically because it was a Proprietary | GPL-3.0 dual license)
<LetoThe2nd>
qschulz: thanks!
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<RP>
jclsn78: how would you want it split up?
mauro_anjo has joined #yocto
lucaceresoli_ has joined #yocto
lucaceresoli__ has quit [Ping timeout: 272 seconds]
manuel1985 has joined #yocto
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #yocto
pgowda_ has joined #yocto
JaMa has quit [Quit: off]
mixfix41 has quit [Ping timeout: 256 seconds]
<RP>
hmm, two ping failures for centos8-ty-2 :(
JaMa has joined #yocto
tre has joined #yocto
<jclsn78>
RP: By chapter I would say. On second thought that would only make sense if the chapters were tags to jump between the files I guess
<jclsn78>
The headlineas are also not bold. It is not nice to read
<rburton>
i'm really curious how well the yocto docs would translate to man pages
<rburton>
(i suspect: not)
<rburton>
you can split per book, but then you have a few very large manpages
<jclsn78>
rburton: it is okay, just not structured
<rburton>
or by chapter, but then you get manpages like yocto-ref-manual-tasks
<jclsn78>
Would be nice to search things like man yocto-layer
<jclsn78>
or man yocto-recipe
<jclsn78>
man yocto-bsp
<jclsn78>
You get the gist
<rburton>
what bit of the docs would those be?
<jclsn78>
No idea
<rburton>
i think that's the important point :)
<jclsn78>
I guess it would be too much work with a questionable outcome
<jclsn78>
Unless you write some skelton for sphinx to parse or somthing
<jclsn78>
I just had the idea while searching through the vim docs
<rburton>
you can generate a mega manpage now. i'd hope it's not a huge amount of effort to get sphinx to split it into separate pages per book. separate pages per chapter might be crazy.
<jclsn78>
You can write your plugin and just type :h something and it appears
<jclsn78>
So convenient
<jclsn78>
Yeah it is okay
<jclsn78>
Just weird that the table of contents is not there
<robertd[m]>
hey guys, I have a question regarding ptest
<robertd[m]>
is there a standard way to grab a file, like a test report, from the qemu target?
<robertd[m]>
I saw `copy_from` function in the oeqa, but it's not being used anywhere in ptest test suite context
<robertd[m]>
any hints?
Guest81 has joined #yocto
<Guest81>
Is yocto no longer allowing building under /usr/local/src? Seems PSEUDO_IGNORE_PATHS complains about overlapping paths. Is that intentional?
<yolo>
4 hours re-learn yocto, so far so good. build a glibc minimal and a musl one, now I need write 10 sample recipes to recall :)
<yolo>
oelint-adv is pretty strict, is there a syntax-format utility for recipe? like clang-format for c|c++
<yolo>
or, if reciple looks very similar to some other formats I can leverage their formatter
pgowda_ has quit [Quit: Connection closed for inactivity]
marc2 has quit [Ping timeout: 268 seconds]
marc2 has joined #yocto
nsbdfl has quit [Ping timeout: 250 seconds]
opello has quit [Remote host closed the connection]
opello has joined #yocto
nsbdfl has joined #yocto
sakoman has quit [Quit: Leaving.]
<khem>
yolo: good progress 4hr .. not bad at all. We do not have an utility to rewrite formatted recipe you can take a look at meta-openembedded/contrib/oe-stylize.py
sakoman has joined #yocto
Minvera has joined #yocto
<yolo>
cool. Thanks!
pasherring has joined #yocto
<pasherring>
Hey there, yoctoers! I've been trying to use dunfell for the past few days and I've been getting a lot of segmenation fault errors during the build... Is there something weird going on upstream, or is it just my setup that should be somehow plagued?
<pasherring>
I mean, the compiler is triggering the segfault
<rburton>
run memcheck
<rburton>
yocto builds thrash your hardware, and bad ram can do that
<pasherring>
rburton, I see. I'll give it a go, thanks! One thing strikes me as strange is that on hardknott, it all builds fine, with no extra tunning required, like BB_NUMBER_THREADS or -l XX -j YY
frieder has quit [Remote host closed the connection]
<RP>
moto-timo: just to add, I tried your test script and it worked for me with my patches
<moto-timo>
RP: that is excellent news... probably my guess at the failure mode was just wrong
* moto-timo
in a meeting but will check soon
rando25892 has quit [Ping timeout: 252 seconds]
pasherring has quit [Quit: Leaving]
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 252 seconds]
mckoan is now known as mckoan|away
rfuentess has quit [Remote host closed the connection]
davidinux has quit [Ping timeout: 240 seconds]
davidinux has joined #yocto
leon-anavi has quit [Quit: Leaving]
amitk has quit [Ping timeout: 240 seconds]
<rfs613>
Am looking at CVE-2021-25219 in package bind... it seems this is fixed in various ways in all active branches, except for dunfell.
<rfs613>
dunfell has 9.11.35 currently, there is an update 9.11.36 which fixes the CVE. So we could either patch, or update to .36, is there a preference?
<rfs613>
also, the 9.11.x series is EOL right now (March 2022), so should dunfell move to 9.16.x? All other branches are on various 9.16.x it seems.
<khem>
bumping major revision in dunfell is kind of risky
<sakoman>
rfs613: is 9.11.36 a security/bug fix release? If no new features I would take a patch for that update.
<rfs613>
i've compiled and tested it locally... only change name of recipe and the sha256sum for the download, all existing OE patches apply. Want me to submit a patch for this?
<sakoman>
rfs613: Thanks for helping with CVEs, I really appreciate it!
<rfs613>
sakoman: i have a few more in the pipe, but let me get this one sorted as first step.
Tokamak has quit [Ping timeout: 240 seconds]
<rfs613>
sakoman: I've been meaning to ask about the repos, as they seem confusing... the patch you linked is in openembedded-core-contrib, but when I look in poky the same commit has a different hash (with a link to OE-Core rev added)
<rfs613>
so how should I do my local workflow to generate patch against correct repo? or does it matter.
<sakoman>
rfs613: Submit patches to oe-core
GNUmoon has quit [Ping timeout: 240 seconds]
<sakoman>
rfs613: poky is a constructed repo -- oe-core + bitbake + meta-yocto + yocto-docs
<sakoman>
rfs613: so patch submissions should be for the base component repo, not poky
<rfs613>
is there a guide to setting up local build using individual repos, rather than the poky constructed one?
<khem>
rfs613: generally patches done on top of poky are directly applicaple to oe-core unless you have local changes
<prabhakarlad>
Hi all, I have tmux package in my rfs, but when I run it I get "tmux: need UTF-8 locale (LC_CTYPE) but have ANSI_X3.4-1968". Any pointers on how to add UTF-8 support in yocto?
<khem>
yocto project consumes openembedded-core + bitbake and create poky repository along with few other layers fudged together
<sakoman>
rfs613: what khem said -- but when you submit, make sure you send the patch to the appropriate component repo mailing list
<rfs613>
sakoman: I sent the mail, but I missed the "Notes for ...", so i'll do a v2 in a moment.
<rfs613>
let me know if this looks okay otherwise
GNUmoon has joined #yocto
Konsgn has joined #yocto
<Konsgn>
Alright, I've been banging my head against a wall for a bit now. I'm trying to get a pocket-beagle design to shutdown properly. Instead, the sysvinit tool halt grabs a system_transition_mutex lock and never lets go causing a stack dump after the umountfs init.d script successfully completes. How can I debug this?
<Konsgn>
looking at the uart output I see that umountfs script complete and the terminal drops back to displaying kernel messages, but I then get a warning that locks are still held by halt, followed by a stacktrace.
<rfs613>
prabhakarlad: not sure what version of yocto you're using, but try checking $LANG as a first step. Or perhaps check the output of "locale" command. I'm guessing you will see "C" rather than something ending in ".UTF-8"
<prabhakarlad>
rfs613: $LANG is C
<khem>
konsgn: I would test same setup on qemuarm and if it works there then its perhaps a beagle kernel issue
<rfs613>
prabhakarlad: so that's probably the reason, ANSI_X3.4-1968 is basically the same as C
<yolo>
can I list all recipes used for an image, e.g. core-image-minimal, bitbake -s seems just list everything possible
<khem>
konsgn: maybe there is some spurious unlock_system_sleep() call in kernel path
chep` has joined #yocto
<prabhakarlad>
rfs613: I see, how can I force it to UTF-8?
<rfs613>
prabhakarlad: well, as a quick test, just try "export LANG=en_US.UTF-8" and then run tmux... if that works, it's just your default locale that's the issue.
<khem>
you might first check if you have locales included see IMAGE_LINGUAS and what it is set to
<Konsgn>
khem, thanks for the pointers. specifically, I do have the beaglebone kernel 5.4 (as opposed to my dunfell at 5.9.16) shutting down gracefully, but it is running systemd as opposed to sysv. How could I check the kernel path?
chep has quit [Ping timeout: 245 seconds]
chep` is now known as chep
<prabhakarlad>
rfs613: that didn't help "tmux: invalid LC_ALL, LC_CTYPE or LANG".
<rfs613>
prabhakarlad: ok, so probaly missing locale support, as khem just noted, check IMAGE_LINGUAS in your config
<khem>
konsgn: perhap trace the halt path in kernel maybe with some kprintfs or something
<Konsgn>
khem: one more note, reboot works fine.
<khem>
yeah reboot and halt are different paths
<Konsgn>
alright, will look into what you said, seeing power/main.c a focus point.
<Saur[m]>
jclsn: Yes, the order of the layers in `BBLAYERS` matters. You typically want layers with higher priority earlier in that list as this, e.g., will affect the order include/require finds files.
<rfs613>
prabhakarlad: so you can try setting it to IMAGE_LINGUAS="en-us" for example
<khem>
prabhakarlad: yeah minimal images are minimal add IMAGE_LINGUAS = "en-us" right
<prabhakarlad>
rfs613: khem: thanks for the pointer Ill give that a try now.
<sakoman>
rfs613: what you sent is fine
<rfs613>
sakoman: v2 is there with the extre line added, take your pick ;-)
<sakoman>
rfs613: I took the first version and I'm testing now. Will try to get it into the 3.1.15 release.
<rfs613>
great thanks!
<khem>
yolo: you can do bitbake -g <your-image> which will generate a file called pn-buildlist which has the info you are seeking
<rfs613>
it seems the bitbake in dunfell branch has changed recently (last few days) to reject the old override syntax. I guess I missed the announcement? Or is this not intentional
<rfs613>
no, never mind, I was on the wrong poky branch.
<moto-timo>
RP: weird, still seeing the same behavior on Debian 11 (bullseye) which is Python 3.9.2 in stock config... I'll see if there is a backport of newer py3
florian_kc has joined #yocto
<prabhakarlad>
rfs613: khem: looks like setting the IMAGE_LINGUAS = "en-us" in conf file is ignored when building minimal image.
<rfs613>
prabhakarlad: indeed, it is set to empty in poky/meta/recipes-core/images/core-image-minimal.bb
<rfs613>
you could comment out that line, or find another way to override it, I suppose
<prabhakarlad>
ouch, i see only option is to comment it, unless there is a graceful way to override it.
<rfs613>
in yocto, there is always a bigger hammer available :-)
<khem>
use core-image-base
<rfs613>
sakoman: next on my list is CVE-2022-23308 in libxml2... it's new this week... got a few moments to discuss that one?
<sakoman>
rfs613: yes
<prabhakarlad>
rfs613: khem: yep looks like I will have to go with core-image-base
<rfs613>
sakoman: so we have 2.9.12 in master branch, and there is a 2.9.13 release whcih fixes the CVE.
<rfs613>
sakoman: it also seems the project has moved from xmlsoft.org to gitlab.gnome.org, so "devtool upgrade" doesn't pick up on the new release.
<sakoman>
rfs613: are you looking to fix in master or in dunfell?
<rfs613>
sakoman: master first, as I know thats teh policy
_wmills has quit [Ping timeout: 256 seconds]
<sakoman>
rfs613: if master, you might be able to sneak in the version upgrade if you work very fast, check with RP to see if he would still take that patch
<sakoman>
rfs613: it would also make sense to fix and broken paths in the recipe before the release
<sakoman>
rfs613: for dunfell it would need to be a CVE patch rather than version upgrade (unless there is a bug fix/security fix only release)
<moto-timo>
RP: confirmed with a toaster-container using master-next and Ubuntu 20.04 that the web UI can build quilt-native
<rfs613>
sakoman: yes, I'm messing with it now, though I will have to break to pickup car and kids soon, so may not have it soon enough for RP
<rfs613>
sakoman: I guess we can try to backport the CVE only to 2.9.10 in dunfell
<sakoman>
rfs613: If you can do it in the next few days it may be fine, but check with RP
<yolo>
khem: thanks that works. is there a command to list the recipes(and/or pkgs) that is only for the target, i.e. the rootfs? bitbake cares about all the recipes(host and target), sometimes I want to know what exactly went to the target rootfs
<sakoman>
rfs613: no time constraints on dunfell -- it will live for another couple of years :-)
<rfs613>
RP: ^^ i'm looking at updating libxml2 version (2.9.12 to 2.9.13) for CVE fix... but also the project download URLs changed (moved to gitlab.gnome.org)
<rfs613>
just a heads up ;-)
<rfs613>
Does it make sense to switch from download .tar.gz to using git instead? Finding non-javascript download links on gitlab seems to be challenging.
<yolo>
to answer my own question: enable buildhistory will give me the target pkg info
florian_kc has quit [Ping timeout: 256 seconds]
<jclsn[m]>
<Saur[m]> "jclsn: Yes, the order of the..." <- Alright thanks
<Konsgn>
well shiver me timbers, I'm hitting the omap_rtc_power_off(void) function just fine, it just doesn't trigger the pmic chip to shutdown somehow.....
mauro_anjo has quit [Ping timeout: 252 seconds]
<khem>
yolo: right, you want to check output packages ( ipk/rpm/deb ) not recipes in that case
<khem>
look under images/ directory in buildhistory
<Konsgn>
khem: yea, that seems very related. Though In my case the bits are set the same btwn yocto's and beaglebones, at least it is the same as:https://github.com/beagleboard/linux/blob/bbf5c979011a099af5dc76498918ed7df445635b/drivers/rtc/rtc-omap.c#L481
manuel1985 has quit [Remote host closed the connection]
manuel1985 has joined #yocto
<khem>
maybe check if right PMIC options are enabled in .config
<rfs613>
RP: although the 2.9 in the pathname is unforunate, not sure if there is a good way to handle that.
florian_kc has joined #yocto
<RP>
rfs613: I'm sure we've dealt with this kind of thing before
<rburton>
rfs613: gnomebase does that for you
<rfs613>
rburton: thanks, I am checking that out now!
<Saur[m]>
yolo: You do not need to enable buildhistory if all you want is a list of the packages that went into an image. E.g., if you build core-image-minimal for qemux86-64 then you should have an `tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.manifest` file that lists all the packages in the image.
<kergoth>
Huh, how did I miss that license_image warns/errors about installing incompatible packages? I can drop an entire class from my layer that did that now. woo
* kergoth
rolls eyes at self
mvlad has quit [Remote host closed the connection]
Tokamak has joined #yocto
<rfs613>
rburton: gnomebase is good! However the original SRC_URL used name=libtar on the end, whereas gnomebase seems to call it "archive". Any idea if this matters?
<wesm>
I am using a different x11 wm than x11-base so I've made my own packagegroup that replaces the one selected by IMAGE_FEATURES. But rootfs-postcommands picks the systemd default.target based only on finding 'x11-base' in IMAGE_FEATURES. What's the correct way to override that bbclass or otherwise set the default.target myself?
florian_kc has quit [Ping timeout: 256 seconds]
<rburton>
rfs613: not at all, just rename any instances, like the checksum
<khem>
how can I extract some extra logs on a failing build on AB
<halstead>
khem: Can I get you set up right now? I think you have an ssh account already.
<khem>
sure
<khem>
I sent my key
<Saur[m]>
Hmm, is it still appropriate to refer to the colon override syntax as "the new override syntax" in a commit message given that we have been using it for quite a while now. On the other hand, I had expected us to have smoked out all use of the old syntax from OE-Core by now, but alas I just found a case of the old syntax in `oe-pkgdata-util` (which resulted in incorrect output for `oe-pkgdata-util package-info`)...
<halstead>
khem: Shall I remove your previous keys?
<khem>
halstead: they are still valid
<RP>
Saur[m]: "the override syntax" is less helpful
<fray>
most people have been using the : syntax for less then a year. I would still call it the 'new' syntax through at least the end of 2022
<khem>
Saur: on universe time scale human civilization is still very new 🙂
<Saur[m]>
:)
<RP>
moto-timo: I guess I should do an upgrade of my system, see if that reproduces :/
<halstead>
khem: Can you try now?
<Saur[m]>
RP: You can find the fix on the `pkj/oe-pkgdata-util` branch in poky-contrib, but I'll send it to the list tomorrow when I'm at the office.
<moto-timo>
RP: it might be something I have on top of master-next. I should try again in a clean environment.
GillesM has quit [Remote host closed the connection]
<RP>
Saur[m]: thanks, I'll queue
lucaceresoli__ has quit [Quit: Leaving]
dmoseley has joined #yocto
<khem>
hmm so pcp issue seems to be specific to fedora35 nodes
<RP>
khem: the failed data is there, just renamed from build/build/ to build/build-renamed/
<RP>
moto-timo: I tried on my 21.10 ubuntu and it shows exit code zero to your test script
Minvera has quit [Remote host closed the connection]
<RP>
moto-timo: and I can run builds ok there using the UI
prabhakarlad has quit [Quit: Client closed]
<moto-timo>
RP: I think we call that bug closed. I must have something else happening.
<RP>
moto-timo: did david see this issue too?
<moto-timo>
RP: I don’t know
<RP>
moto-timo: try with a clean build dir with master-next and see where that gets us...
<khem>
:q:q
* moto-timo
reboots for the first time in a month
manuel1985 has quit [Ping timeout: 240 seconds]
<moto-timo>
RP: yes, exactly. It should work. My container test proves it.
<RP>
moto-timo: I missed that in the scrollback!
<RP>
(the container worked)
<moto-timo>
RP: confirmed. It went away.
* moto-timo
goes to close a bug \o/
<RP>
moto-timo: cool :)
<moto-timo>
RP: thank you so much for figuring this one out.
<RP>
np, happy it is working
<tlwoerner>
RP: i like the new setscene/tasks info layout
florian_kc has joined #yocto
<RP>
tlwoerner: cool :)
<tlwoerner>
also, i don't have the root cause, but the build issue i've been seeing is related to BB_NUMBER_THREADS and PARALLEL_MAKE
<tlwoerner>
i've been able to reproduce it without having to use jenkins, and i've narrowed it down to those 2 variables
<RP>
tlwoerner: likely some kind of race then? :/
<tlwoerner>
RP: yes, i would assume, quilt complains that the patches are already applied. it *only* happens with recipes where the sources are in-layer
<RP>
tlwoerner: is it a task execution issue, i.e. is it running some task twice somehow?
<tlwoerner>
and it only started happening feb 25th (or thereabouts)
<RP>
tlwoerner: you don't have that configured I assume?
<tlwoerner>
yes, because there's really nothing to patch. the source files are in the layer and they're already in the work directory because they're "patches"
<tlwoerner>
a fresh build doesn't show the issue
florian_kc has quit [Ping timeout: 256 seconds]
<tlwoerner>
but if the layers update and a new build occurs, then it might happen. starting with layers a day or two old, building, deleting sstate, updating the layers, then building again will cause it
<tlwoerner>
let me revert that patch and see...
<RP>
so it is some kind of build directory reuse issue
<RP>
tlwoerner: do you have git patch application configured?
<RP>
that code shouldn't be involved otherwise
<tlwoerner>
i'm guessing "no", since i'm not sure what you're saying :-)
<RP>
tlwoerner: right, it defaults to not enabled
<tlwoerner>
anyway, i'll keep poking at it
<RP>
tlwoerner: ok. Just thought i'd mention in case you were using git patching instead of quilt