El vie, 19 jul 2024 a la(s) 9:08 p.m., Justin Yates Fletcher
(jyfletc...@gmail.com) escribió:
>
> On Fri, 2024-07-19 at 17:18 +, Anon Loli wrote:
> > Please stop joking and get serious.
>
> This is my favorite part so far. Everything written on almost every
> post has been hilarious: Inane ramb
On Fri, 2024-07-19 at 17:18 +, Anon Loli wrote:
> Please stop joking and get serious.
This is my favorite part so far. Everything written on almost every
post has been hilarious: Inane ramblings, word salads, delusions of
grandeur, help vampirism, thread hijacking, and even more!
Top level tr
On Thu, Jul 18, 2024 at 11:23:08PM -0400, José Maldonado wrote:
> >
> > I don't really deserve OpenBSD, I get that, but there is a reason as to why
> > Theo De Raadt and other folks are still active on mailing lists and respond
> > to
> > topics like these, everything else should click and make se
fall off (you can
> > still drive with 3 wheels, but like not for long)
>
> You still get to keep all the parts. If you play with power tools
> you can expect to get hurt.
This is why people go insane and do terrorist attacks, because more and more
people don't really giv
>
> I don't really deserve OpenBSD, I get that, but there is a reason as to why
> Theo De Raadt and other folks are still active on mailing lists and respond to
> topics like these, everything else should click and make sense now, I don't
> know how much clearer I can get, low critical thinking is
t; When undoing 1 screw, I didn't expect the whole wheel to fall off (you can
> still drive with 3 wheels, but like not for long)
You still get to keep all the parts. If you play with power tools
you can expect to get hurt.
> > > I didn't change the source code related to X
t to code get coding. If you want a working system that's
> built by others others then put the compiler down and use what they
> have produced.
>
> There is no middle ground. You break it, you get to keep both halves.
When undoing 1 screw, I didn't expect the whole wheel
ing system that's
built by others others then put the compiler down and use what they
have produced.
There is no middle ground. You break it, you get to keep both halves.
> I didn't change the source code related to Xenocara, I was just curious if
> Xenocara compiles with different Mak
.
>
> Once you have crossed this Rubicon you are a developer and On Your Own.
That's mean!
I didn't change the source code related to Xenocara, I was just curious if
Xenocara compiles with different Makefile or something.. it'd be nice if at
least someone told me if it affe
I think there is a fundamental misunderstanding here.
Anon Loli writes:
> Hello list, after I compiled ...
Once you have crossed this Rubicon you are a developer and On Your Own.
Not that OpenBSD was ever going to hold anyone's hand.
Use the source, Luke.
> Does this belong in @tech?
No.
Mat
g (something
like that) and so I had to compile user base/kernel and apply the patch (which
could have maybe been done via syspatch? IDK), so I thought might as well
complete the rest of the release(8) and compile the rest.
> On Tue, Jul 16, 2024 at 12:49 PM Anon Loli wrote:
> >
> >
> I compiled everything
. What's your rationale? Why compile everything from scratch in the first place?
On Tue, Jul 16, 2024 at 12:49 PM Anon Loli wrote:
>
> Hello list, after I compiled Xenocara on my computer (I compiled everything)
> as
> commanded by release(8) sacr
Hello list, after I compiled Xenocara on my computer (I compiled everything) as
commanded by release(8) sacred paper, my "gaming mouse" changed it's behavior
by A LOT.
1st change that I noticed is that the mouse profile which has been set by my
using original software has seemi
Derek wrote:
> Could someone knowledgable with Firefox or Xenocara help explain this?
>
> OpenBSD (amd64) has been my primary desktop OS for 20 years now. Always
> -RELEASE.
>
> In Firefox, to select the contents of the current form field, you used to hit
> Ctrl-a.
>
Could someone knowledgable with Firefox or Xenocara help explain this?
OpenBSD (amd64) has been my primary desktop OS for 20 years now. Always
-RELEASE.
In Firefox, to select the contents of the current form field, you used to hit
Ctrl-a.
Last year, it became Alt-a. I don't know if this
in on the console, edit my
> non-root user, and create the directory structure:
>
> # user mod -G wsrc czakelj
> # cd /usr
> # mkdir -p xenocara ports
> # chgrp wsrc xenocara ports
> # chmod 775 xenocara ports
>
> So far, so good. Next I go to https://www.openbsd.org/anoncvs.
e the directory structure:
# user mod -G wsrc czakelj
# cd /usr
# mkdir -p xenocara ports
# chgrp wsrc xenocara ports
# chmod 775 xenocara ports
So far, so good. Next I go to https://www.openbsd.org/anoncvs.html, log
in non-root via SSH, and begin extracting:
arcbuild$ cd /usr/src
arcbuild$ tar xz
Thus said Jonathan Gray on Mon, 10 Aug 2020 23:54:54 +1000:
> For now we could just skip reading a disabled bios on RV610.
Thanks, that tweak seems to have gotten past the problem and now X will
start:
initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
radeondrm0: 1680x10
On Sun, Aug 09, 2020 at 10:01:43AM -0600, Andy Bradford wrote:
> Thus said Jonathan Gray on Sun, 09 Aug 2020 12:39:36 +1000:
>
> > When this came up previously running i386 resulted in being able to
> > read the atombios. Can you confirm that is the case here?
>
> Yes, this is the case. I inst
Thus said Jonathan Gray on Sun, 09 Aug 2020 12:39:36 +1000:
> When this came up previously running i386 resulted in being able to
> read the atombios. Can you confirm that is the case here?
Yes, this is the case. I installed OpenBSD 6.7 i386 to the same hardware
and there is no error in dm
On Sat, Aug 08, 2020 at 10:23:13AM -0600, Andy Bradford wrote:
> Hello,
>
> The following is found in dmesg:
>
> initializing kernel modesetting (RV610 0x1002:0x94C1 0x1028:0x0D02 0x00).
> drm:pid0:r600_init *ERROR* Expecting atombios for R600 GPU
> drm:pid0:radeondrm_attachhook *ERROR* Fatal err
On Sat, Aug 08, 2020 at 10:23:13AM -0600, Andy Bradford wrote:
> Hello,
>
> I put OpenBSD 6.7 on an older PC that used to run OpenBSD 6.3 and X just
> fine. xenodm refuses to start. Is there something I can do to make this
> work (edit sources in xenocara or kernel and recompi
Hello,
I put OpenBSD 6.7 on an older PC that used to run OpenBSD 6.3 and X just
fine. xenodm refuses to start. Is there something I can do to make this
work (edit sources in xenocara or kernel and recompile), or should I
just email bugs@?
The following is found in dmesg:
initializing
On Mon, Dec 16, 2019 at 10:55:17AM +0530, putridsou...@gmail.com wrote:
> Currently I'm running the -stable OPENBSD-6.6
> I want to set up the ports repository so
> I followed the faqs to set up a /usr/ports partition,
> changed the group to wsrc and file modes to 775.
> Then I added my local user
Currently I'm running the -stable OPENBSD-6.6
I want to set up the ports repository so
I followed the faqs to set up a /usr/ports partition,
changed the group to wsrc and file modes to 775.
Then I added my local user to wsrc group.
After changing directory to /usr, I hit the following
command
cvs
On 2019-12-15 09:42, putridsou...@gmail.com wrote:
> I recently did a checkout of the src,ports and xenocara
> repositories and was greeted by the following message on
> each checkout. After this the command proceeds smoothly.
> Also doing "echo $?" gives "0" so i
I recently did a checkout of the src,ports and xenocara
repositories and was greeted by the following message on
each checkout. After this the command proceeds smoothly.
Also doing "echo $?" gives "0" so it's not a error.
cvs server: duplicate key found for 'y
On Sun, Sep 29, 2019, at 18:53, Jonathan Gray wrote:
>
> suspend/resume currently does not work on amdgpu.
>
> There is a problem with hardware cursor state on amdgpu. As a workaround
> try creating an /etc/X11/xorg.conf with:
>
> Section "Device"
> Identifier "amdgpu"
> Option "SWcursor" "True"
On Sun, Sep 29, 2019 at 06:42:08PM -0700, Travis Cole wrote:
> I've been banging my head on this one long enough that I figured I'd just ask
> the list if anyone else is seeing this behavior.
>
> I'm getting really inconsistent xcursor behavior.
>
> I've tried setting a few xcursor themes, and t
I've been banging my head on this one long enough that I figured I'd just ask
the list if anyone else is seeing this behavior.
I'm getting really inconsistent xcursor behavior.
I've tried setting a few xcursor themes, and they seem to only take
inconsistently.
On certain areas of applications
Hi All
I am trying to update my system from the latest snapshot (success) and then
rebuild everything from source (done many times before).
following release(8), i have been able to build the kernel and base, but not
Xenocara, i get the following error.
checking whether libxcb was compiled
showing exactly what I
> > experience:
> >
> > https://framapic.org/dHfk2217huGs/NIiGKJsfnz52.jpg
> >
> > The problem can be reproduced by specifying "glx" as backend in compton(1).
> > It
> > appear to have been major glx-related imports in Xenocara on
y specifying "glx" as backend in compton(1).
> It
> appear to have been major glx-related imports in Xenocara on January 29th
> 2019.
> My previous snapshot was older than that, perhaps as old as from December
> 2018,
> but for certain newer than the previous bulk import
from that page - a link to a screendump showing exactly what I experience:
https://framapic.org/dHfk2217huGs/NIiGKJsfnz52.jpg
The problem can be reproduced by specifying "glx" as backend in compton(1). It
appear to have been major glx-related imports in Xenocara on January 29th 2019.
M
Hi again!
>> Wipe your build directory and try again. Most likely it has some
>> cache files from a previous autoconf run (mincore recently moved to
>> libc).
> You were spot on: rm -rf /usr/xenocara/* fixed it.
The above is incorrect.
Obviously, what I did was rm -rf /us
Hi!
> Wipe your build directory and try again. Most likely it has some
> cache files from a previous autoconf run (mincore recently moved to
> libc).
You were spot on: rm -rf /usr/xenocara/* fixed it.
Thank you!
- Jyri
On 2019-01-16, Jyri Hovila [Turvamies.fi] wrote:
> Hi!
>
> Anybody else having this issue with compiling CURRENT Xenocara?
>
>====
> /usr/xenocara/lib/mesa/src/egl/main/eglglobals.c:166:8: error: impli
Hi!
Anybody else having this issue with compiling CURRENT Xenocara?
/usr/xenocara/lib/mesa/src/egl/main/eglglobals.c:166:8: error: implicit decla
ration of function 'mincore' is invalid in C99 [-Werror,
Hi,
and thanks for the input!
I now (re)understand the reason to compiling the kernel, the userland and
Xenocara in a single-thread fashion is obviously the correct way, at least when
it comes to doing things properly, minimizing the potential for anything
breaking down.
That said, I
On Mon, Oct 29, 2018 at 08:11:03AM +0200, Jyri Hovila [Turvamies.fi] wrote:
> Hi,
>
> just for the record, and to inform others who may still be at loss regarding
> this matter: when compiling stuff (particularly Big Stuff, such as the
> userland) on an OpenBSD machine with several CPU cores, it
Hi,
just for the record, and to inform others who may still be at loss regarding
this matter: when compiling stuff (particularly Big Stuff, such as the
userland) on an OpenBSD machine with several CPU cores, it's important to pass
the '-j ' argument to the make command, in order to
benefit fro
Hi again,
to elaborate a bit, the reason I'm interested in getting more detailed
benchmark results for the build processes is that I've noticed there are many
situations where servers with less hardware resources (CPU cores and RAM in
particular) often seem to finish the builds quite a lot fast
Hi!
I have a handful of OpenBSD (CURRENT) instances, running on different VPS and
full iron platforms.
Since I use CURRENT, keeping up to date means I have the opportunity to watch
and compare the build process durations of the kernel, the userland, and
Xenocara.
For now, I've simply cl
On March 29, 2018 5:00 PM, Jiri B wrote:
> See https://marc.info/?l=openbsd-misc&m=151877018030790&w=2
>
> Is it relevant?
>
> Jiri
Hi Jiri B!
Thanks for highlighting your post from last month! I skimmed it through
then but couldn't recall it now.
So the whole thread is at https://marc.info/?
See https://marc.info/?l=openbsd-misc&m=151877018030790&w=2
Is it relevant?
Jiri
Hi misc@,
I did not find any mentioning of OpenBSD Xenocara use of the "dummy"
video driver on mailing list nor web. Digging into code and
documentation, I think it looks like it's available and should work.
I'll try this out soon, this is mostly to mention the topic and to
On Wed, 7 Mar 2018 05:34:00 +0200
> It seems (quite obvious) to me that OpenBSD / Xenocara do not
> currently have mechanisms to limit which processes / applications can
> access the contents of the screen.
Of course you do need access to initiate a screenshot command and CAN
limit wh
On Wed, 7 Mar 2018 05:34:00 +0200
> The APIs of Windows, Android, iOS etc. allow capturing the screen
> without informing the user about it in any way.
The signal app on android asks/prevents screen captures. The lock
screen of the OS can hide details too.
contents of the screen is one of the many design
> level security / privacy issues all major operating systems suffer from. The
> APIs of Windows, Android, iOS etc. allow capturing the screen without
> informing the user about it in any way.
>
> It seems (quite obvious) to me
e possibility to grab the contents of the screen is one of the many design
> level security / privacy issues all major operating systems suffer from. The
> APIs of Windows, Android, iOS etc. allow capturing the screen without
> informing the user about it in any way.
>
> It seems (quit
(quite obvious) to me that OpenBSD / Xenocara do not currently have
mechanisms to limit which processes / applications can access the contents of
the screen. I can already feel the storm brewing but I must ask: have there
been any plans regarding such a feature?
Yours,
Jyri
--
jyri.hov...@iki.fi
Hi Thomas,
> The OpenBSD homepage describes a preferred license. It's the first link on
> https://www.openbsd.org/policy.html
Thanks very much. Licensed it OpenBSD style. :-)
https://github.com/hakrtech/reladm/blob/master/LICENSE
with a basic README
https://github.com/hakrtech/reladm/blob/ma
man release rocks), but that might be a daunting for a person
>just getting into the UNIX/OpenBSD world.
>
>So, I wrote some syntactic sugar which makes it very easy:
>
>doas mkkern.sh # compile kernel
>doas mkbase.sh # compile base
>doas mkxeno.sh # compile xenocara
>doas
# compile base
doas mkxeno.sh # compile xenocara
doas mkrel.sh # cut an iso
You can get it from:
https://github.com/hakrtech/reladm.git
Usage Instructions at:
https://github.com/hakrtech/src/wiki/Home
I would also like to give back by appropriately OpenBSD style/philosophy
licensing it. I have not
Xenocara incorrectly selects "EXA" acceleration method instead of
"glamor" for my Radeon HD 7670 (TURKS) video card, which results in
bizzare, unusable display in Xorg. Adding the following config file,
named "10-display.conf" in /usr/X11R6/share/X11/xorg.conf.
For xenocara i followed the faq. For ports if you want to follow stable
then dpb worked with 777.It was 775 but dpb didnt work. I tried to
change the owner and permissions of {DISTDIR},{PORTSDIR} {WRKOBJDIR}
{PACKAGE_REPOSITORY} and {PLIST_REPOSITORY} to _pbuild but it still
failed to build the
What are the "best practices" file and directory permissions within
the /usr/{src,xenocara,ports} trees in the context of anonymous-cvs
updating?
http://www.openbsd.org/faq/faq5.html#wsrc suggests that the top-level
directories /usr/{xenocara,ports} should be mode 775, but doesn&
to just 'stick' to keep in line with other actions, like
'freeze', 'hide', raise', 'lower', etc...I'd prefer to change the group
meaning of 'sticky' but that breaks most people's config :(
Thanks,
Okan
> Index: conf.c
>
On Sat, September 10, 2016 4:14 pm, Stephen Trotter wrote:
> hi, I am just curious if the defaults (namely the disk sizes) are supposed
> to be sufficient for building xenocara after a fresh install.
>
> i attempted to do so following release(8) and it ended unsuccessfully due
&g
hi, I am just curious if the defaults (namely the disk sizes) are supposed
to be sufficient for building xenocara after a fresh install.
i attempted to do so following release(8) and it ended unsuccessfully due
to the drive/filesystem being full.
(it does seem to have almost finished, by the way
receive "syntax error".
>
> I check the codes and found out that in parse.y file "sticky" is a keyword.
>
> I don't know which is the best patch for this problem, but this patch works
> for me:
>
> Index: conf.c
> ==
or this problem, but this patch works
for me:
Index: conf.c
===
RCS file: /usr/cvs/xenocara/app/cwm/conf.c,v
retrieving revision 1.204
diff -u -p -r1.204 conf.c
--- conf.c 13 Aug 2016 09:59:48 - 1.204
+++ conf.c
On Thu, May 19, 2016 at 4:56 AM, Jiri Navratil wrote:
> Hi,
>
> On Fri, May 13, 2016 at 07:21:00PM +,
> 3ss7cb+angubqwtnb...@guerrillamail.com wrote:
>>
>> How should I set
>> my mouse as favourite input system instead of the trackpad?
>>
>> I am runnning 5.9
>> with Xfce4.
If your objective
Hi,
On Fri, May 13, 2016 at 07:21:00PM +,
3ss7cb+angubqwtnb...@guerrillamail.com wrote:
>
> How should I set
> my mouse as favourite input system instead of the trackpad?
>
> I am runnning 5.9
> with Xfce4.
>
in my case, mouse is enabled without need to change anything, I just
plug-in USB
Hi,
I din't find informations on this subject in the FAQ...
How should I set
my mouse as favourite input system instead of the trackpad?
I am runnning 5.9
with Xfce4.
Sent using GuerrillaMail.com
Block or report abuse:
https://www.guerrillamail.com/abuse/?a=TEhnBi0PU7Ebih2wvnENdQ%3D%3D
n with -current
> and 5.9.
>
> The handful of southern islands parts the kernel knows about
> (TAHITI/PITCAIRN/CAPE VERDE) need a version of Mesa compiled
> against a newish version of LLVM (which we can't use from xenocara
> currently) then Mesa needs to be compiled wit
N/CAPE VERDE) need a version of Mesa compiled
against a newish version of LLVM (which we can't use from xenocara
currently) then Mesa needs to be compiled with a version of gcc
from ports due to the llvm headers/libraries requiring things
from recent c++ standards.
Is it the case that 3D acceleration does not work for AMD
PITCAIRN-based GPUs in X on OpenBSD 5.8?
Is there any documents describing what features work on what GPUs?
Thanks!
--
Håvard Farberg
Hi,
X was crashing every N minutes after disabling 2D acceleration for
Broadwell (as discussed on @tech)
Recent commit (3rd Dec 2015) will produce unusable garbled output with
sluggish / frozen output on the same machine.
Cheers,
nuc$ cat /var/log/Xorg.0.log
[69.023] (--) checkDevMem: using
Hi misc@,
For a couple of weeks, I am not able to build Xenocara on -current
(even after a fresh cvs update or checkout, and manually install the
sets) anymore.
OpenBSD 5.7 GENERIC.MP#44 amd64
I have got the following errors:
cc -shared -fpic -o radeonsi_dri.so `lorder dri_context.so
> So I don't know what was the problem, but I know that wasn't with openbsd.
Like somebody said before, you were running OpenBSD -frankenstein flavour.
On Mon, Feb 23, 2015 at 07:40:00AM -0500, Nick Holland wrote:
> On 02/22/15 16:24, Henrique Lengler wrote:
> > On Sun, Feb 22, 2015 at 02:57:18PM -0600, Edgar Pettijohn wrote:
> >> Are you following this?
> >> http://www.openbsd.org/faq/faq5.html#Xbld
> ...
> > Yes I am, and this is my second attem
On 02/22/15 16:24, Henrique Lengler wrote:
> On Sun, Feb 22, 2015 at 02:57:18PM -0600, Edgar Pettijohn wrote:
>> Are you following this?
>> http://www.openbsd.org/faq/faq5.html#Xbld
...
> Yes I am, and this is my second attempt.
...
Start at the very very very top of the page
http://www.openbs
/share/mk/bsd.xorg.mk:145 'all')
> *** Error 1 in app/xfs (/usr/X11R6/share/mk/bsd.xorg.mk:211 'build')
> *** Error 1 in app (:48 'build')
> *** Error 1 in . (:48 'realbuild')
> *** Error 1 in /usr/xenocara (Makefile:36 'build')
Sorry this the same message. I'm thinking about thrust that everything should
work,
and reintall the whole system.
--
Regards
Henrique Lengler
** Error 1 in app/xfs/obj (Makefile:407 'all')
*** Error 1 in app/xfs (/usr/X11R6/share/mk/bsd.xorg.mk:145 'all')
*** Error 1 in app/xfs (/usr/X11R6/share/mk/bsd.xorg.mk:211 'build')
*** Error 1 in app (:48 'build')
*** Error 1 in . (:48 'realbuild')
*** Error 1 in /usr/xenocara (Makefile:36 'build')
--
Regards
Henrique Lengler
Hi, I'm moving my system from -release to -stable, I'm following
the instructions here: www.openbsd.org/stable.html.
I already built the kernel, rebooted amd built the userland.
Now that its time to build xenocara, the process fails.
This is the second attempt to build, when it failed
"STeve Andre'":
> Every once in a while compiling xenocara, I get a fatal error when
> dealing with kdrive. [...]
> Since others aren't complaining about this it must be me. So then,
> how am I shooting myself (this time) ? Clue sticks? Error below.
>
So, I am dumb. Problem is, I don't know what it is that I don't know.
Every once in a while compiling xenocara, I get a fatal error when
dealing with kdrive. I've looked for emails talking about this and
haven't found anything. I've gone over release(8) and think I&
Hi Joel,
Joel Rees wrote on Thu, Aug 28, 2014 at 03:26:58PM +0900:
> Oh, BTW, the output of the command Ingo suggested,
>
>find /usr/ports -name pobj -prune -o -type d -empty -print
>
> is empty.
Well, your checkout should be fine, then. Pruning directories
only starts after the update is
On 08/28/14 02:26, Joel Rees wrote:
> Finally getting a chance to look at this again, and I had a couple of
> questions.
>
> One, am I right that cvs co and cvs get are basically the same thing?
>
> (get, per http://www.openbsd.org/anoncvs.html ,
> and co, per http://www.openbsd.org/faq/faq5.html#
Finally getting a chance to look at this again, and I had a couple of
questions.
One, am I right that cvs co and cvs get are basically the same thing?
(get, per http://www.openbsd.org/anoncvs.html ,
and co, per http://www.openbsd.org/faq/faq5.html#Bld .)
The other, assuming that the last package
Hi Joel,
Joel Rees wrote on Mon, Aug 18, 2014 at 08:27:23PM +0900:
> $ date
> Mon Aug 18 19:09:34 JST 2014
> $ sudo cvs -d$CVSROOT co -P ports
Unrelated:
There is no need to check out the source trees as root.
Just chmod -R the whole things to a regular user account
(for example your own) and us
anks for all the answers. Particularly this:
>
> On Fri, Aug 15, 2014 at 9:05 PM, Benjamin Baier
> wrote:
>> Here are the newest numbers i can provide for a full build from source.
>> /usr/src >900MB
>> /usr/xenocara >700MB
>> /usr/obj >900MB
>>
Thanks for all the answers. Particularly this:
On Fri, Aug 15, 2014 at 9:05 PM, Benjamin Baier wrote:
> Here are the newest numbers i can provide for a full build from source.
> /usr/src >900MB
> /usr/xenocara >700MB
> /usr/obj >900MB
> /usr/xobj >500MB
> /usr/
Here are the newest numbers i can provide for a full build from source.
/usr/src >900MB
/usr/xenocara >700MB
/usr/obj >900MB
/usr/xobj >500MB
/usr/ports >600MB
/usr/ports/pobj can't be big enought...
On 08/15/14 05:09, Joel Rees wrote:
I'm trying re-learn how to
and it was 90% full when I finished unpacking
the sys, src, ports, and xenocara tarballs.
(ancient IBM thinkpad with only 256M RAM and 20G (17 real gig) or hard
disk. 860 MHz or so CPU.)
I had saved 2.5G out of the suggested size for /home, so I cut a 1G
partition for /usr/ports and gave it the def
after setting a breakpoint on xf86CVTMode, I stepped through it, and
> > at the end, Mode was:
> >
> > (gdb)
> > 295 return Mode;
> > (gdb) print Mode
> > $3 = (DisplayModeRec *) 0x3bc16033800
> >
>
> Full 64bit pointer there...
>
>
&g
)
> 295 return Mode;
> (gdb) print Mode
> $3 = (DisplayModeRec *) 0x3bc16033800
>
Full 64bit pointer there...
NVPreInit (pScrn=0x3bc16035800, flags=0) at
> /home/xenocara/driver/xf86-video-nv/src/nv_driver.c:1929
> 1929Mode->type = M_T_DRIVER;
> (gd
rg.0.log, xdm.log and dmesg below.
> >
> > So I went back, installed a 5.5 release, where starting X just worked.
> >
> > Afterward again, back to the snapshot.
> >
> > I built, xenocara with debug symbols, following instructions
> > in the README, giving me th
tarting X just worked.
>
> Afterward again, back to the snapshot.
>
> I built, xenocara with debug symbols, following instructions
> in the README, giving me the following backtrace:
>
> (gdb) bt
> #0 0x133e268f0fea in kill () at :2
> #1 0x133e26953239 in abor
Hi,
yesterday I updated my desktop from a 5.2 or 5.3, to a current snapshot, now to
find
the X server dying on me. See Xorg.0.log, xdm.log and dmesg below.
So I went back, installed a 5.5 release, where starting X just worked.
Afterward again, back to the snapshot.
I built, xenocara with
On Sun, Jun 02, 2013 at 05:16:19PM -0700, sh...@lavabit.com wrote:
> I am trying to find information about what /base/xenocara/meta is for and
> how it compares to what's in CVS. Using -stable, I am trying to figure out
> if I should build /meta/xenocara or if I should use what
I am trying to find information about what /base/xenocara/meta is for and
how it compares to what's in CVS. Using -stable, I am trying to figure out
if I should build /meta/xenocara or if I should use what is in cvs for
running X. Where can I find info to understand how they distinguish from
output. I have exactly one modified file in my xenocara tree.
> It's not in the lib subdir. I have a few more modifications in my src tree,
> but none in nsd which is the code that wasn't up to date.
>
>
> Otto Moerbeek wrote:
>
>> I believe others have seen p
On 2013-05-14, Marco S Hyman wrote:
>> What is the revision of the file? Any sticky tags/dates?
>>
>> rev should be 1.1.1.2
>
> You are on to something... cvs up -PAd should remove all tags, no? It
> didn't.
I have significantly fewer problems if I explicitly set the root on
the command line:
On May 14, 2013, at 2:07 PM, patrick keshishian wrote:
>
> and none of those files were locally modified? Do you have the output
> of "cvs up -PAd" in regard to those specific files?
There was no output. I have exactly one modified file in my xenocara tree.
It's no
7;t. There's a bug somewhere in cvs.
>
> *nod* Trashing the source and fetching from scratch showed a few things
> stuck at older tags. The nsd sources in src and several things in xenocara
> including freetype and Xfont.
>
> In any case my compile issue is resolved. Thanks
ug somewhere in cvs.
>
> *nod* Trashing the source and fetching from scratch showed a few things
> stuck at older tags. The nsd sources in src and several things in xenocara
> including freetype and Xfont.
and none of those files were locally modified? Do you have the output
of "cvs up -PAd" in regard to those specific files?
--patrick
howed a few things
stuck at older tags. The nsd sources in src and several things in xenocara
including freetype and Xfont.
In any case my compile issue is resolved. Thanks to those who provided help.
On Tue, May 14, 2013 at 11:38, Marco S Hyman wrote:
>> What is the revision of the file? Any sticky tags/dates?
>>
>> rev should be 1.1.1.2
>
> You are on to something... cvs up -PAd should remove all tags, no? It
> didn't.
> When I moved t1load.h out of the way and re-updated I got a different
1 - 100 of 356 matches
Mail list logo
