The problem is that our mixers don't provide a smooth range 0..255
(scaled to 0..100 by the OSS emulation) but will ratchet up to the
next supported value. The details may vary with the sound hardware,
on my laptops (clcs, auich) the step size is 8. mp3blaster tries
to adjust the
Now that mozilla has been switched to gtk+2 a lot of people will get
bitten by the fact that for some bizarre reason the emacs mode is no
longer default in the gtk+2 settings as someone pointed out on this
list a few weeks ago. This means that the standard ^U, ^A, ^E etc.
emacs commands
I believe using -fno-stack-protector is correct in this case.
Note that this is in Makefile.target, which is used to compile 'opcodes'
for the emulated processor. And propolice interferes with that
(even if it works, it would slow the emulation by doing its checks
for every 'instruction')
The following PR numbers appear to still be open. Perhaps ports people
have not noticed.
4473 bugs portsopen serious medium netgnome-panel
freeze and quits on OpenBSD 3.8 current i386
4474 bugs portsopen serious medium netXChat quits
I was trying to build www/opera on my 3.8 (from CD) box
emulators/redhat/base hung up with some error message like:
xargs: unknown option -- r
To fix it I installed and symlinked GNU xargs. I don't know if there is
possibly a better fix that should be implemented into the port itself,
Wel. had you looked at the second hit (really near the top,
so boredom should not have set in yet) searching for why it was a hit
you would have seen several instances of str*** func calls being
replaced by strn*** func when the str ones were unsafe. Seeing that it
was all about a
Rod.. Whitworth wrote:
/* Made up example of course */
- if (!strcmp(buf,n/a))
+ if (!strncmp(buf,n/a,3))
you would have seen several instances of str*** func calls being
replaced by strn*** func when the str ones were unsafe. Seeing that it
The one has little to do with the other.
I still wish someone would properly audit libexpat. I looked at it,
and I was totally terrified. Poeple actually use software that uses
something written this poorly?
On Mon, Apr 30, 2007 at 10:20:37AM -0500, Travers Buda wrote:
Point is, the unencumbered port works, no point in removing it over spite.
http://article.gmane.org/gmane.comp.window-managers.ion.general/7694
The author believes the license change to be retroactive (even though
that's
On Mon, Apr 30, 2007 at 06:25:21PM +0200, Marc Balmer wrote:
The ports tree is here for our users convenience. If a port has a
strange license, you can always set the PERMIT_xy fields. Many users
use ion, so why should we harrass them?
It was not a simple question of removing the port
* Todd T. Fries [2007-05-10]:
There is an expat in src/. What are the plans for that? Would solve
a lot of `must install xbase in order to get expat' complaints. The
counter is that one already installs xbase to get libs.
My understanding is, that it won't be activated until it's
I agree with you on this -current/-stable thingy. This ports tree
soft locking shit *how we care about -stable users* is bullshit,
when outdated/security vulnerable stuff is even in -current and
it takes ages to backport and make packages of needed security updates...
I see there no logic,
- strcpy (s, str);
Yes, the old code is totally wrong for using strcpy.
+ strncpy (s, str, sizeof(s));
And whoever tried to fix it, made it even worse. Now it only copies
either 4 bytes, 8 bytes, or the size of the destination buffer if it
is not a pointer (and it is a pointer, isn't it).
Except that is not a fix. It indicates the application (or some library
it is using) is violating the X security extension. Meaning that if
someone can misuse/fool such an application, it cannot just render into
it's window, but totally take over your X server from remote.
Lovely. The gtk
How about using the source if it's available and using the binary
when it's not?
Right. And in 5 years, how much source will you have?
Don't forget, having the source also means being able to patch it
as well.
Duh.
The point of Christian's mail was is that we all understand how these
Leave installing the source as an option to the user, and install
binaries as a default.
And in 5 years noone will make source available.
P.S. Good time to re-read Ken's paper Reflections on Trusting
Trust (online at http://www.acm.org/classics/sep95/), before you decide
where to put your foot down.
Wow, that is totally off-topic.
The discussion is about how we can use some of our clout to encourage
source availability in the
It's pervert to have a STOP BLOB release theme and then importing
exactly BLOBS in the ports tree. There is absolutely no need to do so,
nothing suffers from going throught the source, besides, maybe these
ports are a little bit harder to do.
Please do not misuse the term BLOB like this.
Why?
A little consistency never hurts (src.tar.gz and srcsys.tar.gz too).
ports have so many disadvantages.
Yeah, sure. If OpenBSD would start to ship incomplete ports,
I hope people who want control back start using the MirPorts
Framework.
Ok, I've had enough. I have to speak up.
On Thu, 26 Oct 2006, [EMAIL PROTECTED] wrote:
Then it`s sad that the port was marked for 4.0...
Your ignorance continues to astound, *it isn't* marked for 4.0.
Sometimes it is easier to work on something in-tree.
-d
Damien, briefly.. you`re talking junk.
No, Damien is tell the
And be super careful about this in anything else which interfaces
to bpf or pcap. The pcap people were super uncareful using a
machine-dependent structure.
This diff fixes unified logging/alerting on 64-bit platforms.
http://secure.lv/~nikns/stuff/ports/snort-2.6.0.2p1.diff
...
+---
Stefan Sperling [EMAIL PROTECTED] wrote:
This patch has been sitting on the list for a month now.
Can someone please commit this?
Theo has requested that pptp should not set net.inet.gre.allow=1
when the package is installed, but only when the program is run,
i.e., add corresponding
But if we don't want to allow 'pkg_add pptp' to enable
an insecure protocol, why do we want to allow executing
pptp to do so?
Isn't the idea to have the user _manually_ turn a knob
if that knob makes the system more insecure?
This is rather simple to break apart.
installing a package does
On 2007-11-16, Stuart Henderson [EMAIL PROTECTED] wrote:
The version in tree is before the license change; the additional
restrictions on the newer code are a problem.
They are not a problem for reasonable distributors that care to pay
a bit of respect
Please immediately take this to your own list, instead of spamming
this list further.
On 2007-11-17 22:10 +0530, Siju George wrote:
See it is not the OpenBSD people who tarnishes you.
It is your own license restrictions that are working against you.
The extra terms in the license are
On Thu, Apr 24, 2008 at 9:05 PM, Chris Kuethe [EMAIL PROTECTED] wrot=
e:
On Thu, Apr 24, 2008 at 4:46 PM, Andr=E9s [EMAIL PROTECTED] wrote:
Why?
Because ports is about getting things done, and code that gets in the
way of you getting things done must die.
Apply your patches
2008/4/25 Theo de Raadt [EMAIL PROTECTED]:
Thank you very much for your opinion, but it is clear you come
with an agenda.
The OpenBSD project people do not follow the bend to Adobe agenda
that some xpdf people follow.
While it's always nice to blame Adobe, please first discuss
2008/4/25 Deanna Phillips [EMAIL PROTECTED]:
You mean this part?
For those who would argue that important content might get
irretrievably locked away in PDF format, I'll remind you that
Xpdf is open source, and can be modified by end users (the GPL
even allows this).
While an
Arnaud Bergeron [EMAIL PROTECTED] writes:
mt-daapd suffers from a case I've named 0.5:
pointer - int
and then the int is used as a truth value. So this is not a bug.
Not a bug? Really?
$ cat foo.c
int
main()
{
int true;
void *nonnull = (void
On Mon, 28.07.2008 at 17:24:01 -0700, Peter Valchev [EMAIL PROTECTED] wrote:
We are in release mode, with 4.4 just around the corner. This means
that from now, no more commits to ports unless they are VERY urgent -
such as fixing a broken dependency, high impact security issue, etc,
I'd
Theo wrote:
Yes, and sometimes tough love is required.
Perhaps whoever the maintainer is will merge this in time.
Perhaps not.
Let me pose a question:
Would you rather have a good release that has good quality
integration between packages
or
One that has the latest
Can I safely assume that 4.4-beta binaries will be compatible with
4.4-release? That is, no shared libraries major number will be bumped.
You can assume nothing until release.
On Jun 12, 2011, at 13:14, Marc Espie es...@nerim.net wrote:
On Sun, Jun 12, 2011 at 10:13:34AM -0500, Chris Bennett wrote:
I ran into a module on cpan that the author says is licensed as:
You can use this module freely. (Someone complained this is too vague.
So, more precisely: do whatever
* GNU part 1: GCC
GCC and related toolchain products put stuff under CONFIG, defined
as ${MACHINE_ARCH}-unknown-openbsd${OSREV}.
devel/libf2c
devel/libf2c-old
lang/g77
lang/g77-old
lang/gcc/3.3
lang/gcc/4.2
lang/gfortran
lang/llvm-gcc4
In principle
Where can I find the information, when the ports tree is being
un/locked?
In OpenBSD, the lock and unlock schedules are a complete shock even to
senior developers. They are often scheduled completely arbitrarily
based on my needs, so that I can make a high quality release, on a
schedule that
I know we can't import new directories yet, but reviews and/or OKs?
You can now. The ports tree is fully unlocked.
I asked Colin privately about the RESTRICTED marker, and he replied with
(paraphrased) the license is nonstandard, and I didn't want to bother
the release manager. I think the license is fairly clear, but I'd be
willing to get (public) clarification of any issues you have.
I think the
I'm not subscribed to the list, but I was pointed towards the discussion here
and would like to respond to a couple points:
Brynet wrote:
http://www.tarsnap.com/legal-why.html#NOCANADIANS
Does not want me.
Do. Not. Want.
I'm a Canadian. Most of my friends are Canadian. I don't
On 03/16/11 12:24, Theo de Raadt wrote:
One word can change the meaning of a sentence. You failed at what you
intended, and you also confused people.
You're the only person who has ever told me that the Tarsnap license is
confusing. Maybe everybody else was confused but didn't want
Hmm.. kinda feels like a waste to create a new user/group.
The app doesn't write to any files nor does it have any
config files (ATM).
How about I stick with nobody?
How about everyone just share the root account?
What are you afraid of, that we'll run out of users and groups?
There are
On Mon, Jun 01, 2009 at 11:20:19PM -0600, Theo de Raadt wrote:
Hmm.. kinda feels like a waste to create a new user/group.
The app doesn't write to any files nor does it have any
config files (ATM).
How about I stick with nobody?
How about everyone just share the root account
It would take a lot more than change of license for
Opera to be available on CD. It has to be Open Source project.
Where does it say that the packages on CD must only be open-source?
I say so.
Is that enough?
What architectures are getting packages for the 4.6 release?
Probably I am going to ask a stupid question but it is very interesting for
me. Because I would like to help BSD projects.
Why OpenBSD does not use pkgsrc of NetBSD project as default ports? I guess
work can be faster in case port system is shared between BSD projects
including FreeBSD.
I am sorry. Really, I don't want to have support here. I just would like to
know relationship between pkgsrc and original OpenBSD port system.
A lot of English is spoken in India because the British used to be there
a long time ago.
How does it change anything if you know the relationship?
Probably I am going to ask a stupid question but it is very interesting
for
me. Because I would like to help BSD projects.
Why OpenBSD does not use pkgsrc of NetBSD project as default ports? I
guess
work can be faster in case port system is shared between BSD projects
including
i dont see how this is stupid...
Don't worry. Most of us see your name and at that moment delete
the mail. This reply is an exception.
2009/10/8 Stuart Henderson st...@openbsd.org:
If you want something better, download SHA256 and check the hashes.
I know this has been discussed before, but other free OS solve this
problem (among others) by signing their packages. Feel free to flame me.
Solve the problem that all the
Mirrors pull from other mirrors, with this method some mirrors
will do their own lock handling, others will just rsync the lock
files from their upstream and you'll end up with a broken mirror
that looks valid. Or something may go wrong and a transfer only
goes halfway while indicating
I got the following error while moving through the screens in pftop:
Error Reading Anchor / (DIOCGETRULES): Permission denied
Anybody else getting this error? This was from packages.
Non-root cannot read that. It is security sensitive. Isn't that
obvious?
I would tend to disagree. Please consider adding section names in national
languages. makewhatis already does so, it's completely harmless.
Formated.pm:if
(m/^(?:NAME|NAMES|NAMN|NOMBRE|NOME|Name|\xbe|\xcc\xbe\xbe\xce|\xcc\xbe\xc1\xb0)\s*$/)
{
I intensely dislike this since it
On Sun, Apr 04, 2010 at 05:05:40PM +, Christian Weisgerber wrote:
Marc Espie es...@nerim.net wrote:
I would tend to disagree. Please consider adding section names in national
languages. makewhatis already does so, it's completely harmless.
Formated.pm:if
Everytime an architecture switches to GCC4, there are dependency
changes for all ports that use MODULES=gcc4 and C++ on that arch.
Normally, this would require a PKGNAME bump. On the other hand,
the gcc4 switch is something of a flag day for that arch anyway.
So...
... to bump or not to bump?
On Mon, Dec 1, 2008 at 12:21 PM, Marc Balmer [EMAIL PROTECTED] wrote:
* Ian Darwin wrote:
Gypsy was designed to fix the numerous design flaws found in GPSD.
These are compiled at http://gypsy.freedesktop.org/why-not-gpsd.html.
So how does this compare to gpsd for real applications? I
So how does this compare to gpsd for real applications? I am asking
since the main gpsd developer is also an OpenBSD developer, and maybe
there are ways to fix the problems in gpsd?
Oh, and I find this rude.
DBUS is more crap I don't need or want on my machines, the
.It Fl M
Show the install-message file (if any) for each package.
+If any step not documented in the manual must be taken before a package
+can be used, this file will often mention it.
That is an attempt to entirely push the problem under the table.
The default message should be relevant.
Another way to solve this is a rewrite of pod2man .. which will then
generate mandoc instead.
That also benefits the other manual page project.
Actually, this is more complex than it looks, because recent pod converters
make a lot of use of
.ie n
.el
constructions, and that throws
On Sun, Mar 22, 2009 at 12:47:28AM -0600, Theo de Raadt wrote:
Another way to solve this is a rewrite of pod2man .. which will then
generate mandoc instead.
That also benefits the other manual page project.
hum... so let's trade 10 lines of makewhatis to a complete new back-end
On Thu, Mar 26, 2009 at 01:36:00PM +0100, Daniel Hartmeier wrote:
On Thu, Mar 26, 2009 at 01:11:49PM +0100, Markus Lude wrote:
Hello,
after updating to the recent snapshot from march 24th I now get errors
when running pfstat:
ioctl: DIOCIGETIFACES: Operation not supported by
The $PACKAGE_REPOSITORY directory, typically /usr/ports/packages/, will
normally contain subdirectories for arch, as well as, further
subdirectories for desired\allowed redistribution (cdrom, ftp, ...).
No, we don't do that.
/usr/ports/packages/i386/
/usr/ports/packages/i386/all
On Mon, 04 May 2009 07:31:39 +0200, Matthew Szudzik wrote:
One of the xenocara font configuration files is interfering with the
/x11/msttcorefonts port. See
http://marc.info/?l=openbsd-miscm=124141462930332
Perhaps the port should be updated, so that the configuration file is
hmm, on Mon, May 04, 2009 at 05:29:02PM +0200, Marc Espie said that
They assume you will always have the microsoft core fonts installed,
even though these basically ARE NOT open source.
if i am not mistaken generic names like times, helvetica,
courier, etc are used by more foundries, not
well, i dont have even have firefox installed. why should i care?
I did not realize we were developing OpenBSD just for you.
now i will have to override an override to get the expected
behaviour. since when is openbsd firefox's bitch?
Your attitude is not very nice.
hmm, on Mon, May 04, 2009 at 05:29:02PM +0200, Marc Espie said that
You want the msttcorefonts ? install them... True, adding a fonts.conf
snippet when you install them so they get used would make sense.
if anything, openbsd should package a fonts.conf with the firefox
package instead.
hmm, on Mon, May 04, 2009 at 12:26:35PM -0600, Theo de Raadt said that
well, i dont have even have firefox installed. why should i care?
I did not realize we were developing OpenBSD just for you.
i did not realize openbsd was developed for firefox.
what i was trying to say, why
hmm, on Mon, May 04, 2009 at 10:18:59PM +0200, Claudio Jeker said that
Sorry you blame the wrong people. Get us free helvetica, times, and all
i am not blaming anyone. but the whole system is being changed
because one application is misbehaving. it is not making a
whole class of problems
hmm, on Mon, May 04, 2009 at 07:58:54PM -0600, Theo de Raadt said that
if an application is broken, fix it or make a cludge in the package.
this is the ports approach.
where's the diffs?
the diffs in the tree, only in the wrong directory.
just put it in your home or install
ppruett-lists writes:
I happened to put in my /etc/mk.conf
MANPS=1
...
And lol, I got a install error, for the package graphics/png
I would not expect MANPS to work. The problem is probably more than
only one package. 'man 7 ports' says this:
BUGS
Use of the MANPS and MANZ
I used to run all my OpenBSD servers with no X11.
Now, to build nmap, you seem to need python. There are no FLAVORS and
so no obvious way to prevent it from requiring python.
And to build python, you need X11R6 installed. There are no FLAVORS
as there used to be, to compile without
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0 and
allowaperture=2...
I don't know this area at all
On 2010/06/25 08:32, Theo de Raadt wrote:
you're in CC of this mail because you sent the unbreak pciutils mail
to this list, and the failure mode is related.
http://marc.info/?l=openbsd-portsm=126918139214769
Hmmm... So why is PCIOCWRITE failing, even when securelevel is 0
I think I should clarify a bit what flashrom (BIOS/EFI/optionROM
flasher) does/needs.
PCI config space writes (usually only to the PCI-LPC bridge) are
needed to tell that bridge to enable pass through for flash chip accesses.
I/O port access is needed on some chipsets which have the
Stuart Henderson wrote:
Port attached and at http://spacehopper.org/flashrom.tgz; this is
basically your patches with a typo fixed (missing ; in the Makefile).
You can see exampkle output from an unsuccessful run on amd64
attempting to dump rom contents at
OpenCT has been broken by the recent commit of SO_PEERCRED:
socket.c: In function `ct_socket_getcreds':
socket.c:298: error: storage size of `creds' isn't known
This is because we use struct sockpeercred instead of struct ucred
to return the credentials in. The following patch fixes it.
Is someone working in full Ada support (GCC GNAT) for OpenBSD?
No. We got out of the cruise missile business a long time ago, since
we don't think it is nice to explode villagers back to the dark ages.
The latest available package is gnat-4.2.4p1v0 (gcc-4.2.4p0v0),
but with incomplete
Recently I discovered that in order to build a port (specifically the
syslog-ng port) that my OpenBSD would need to have X11
installed. Other than for this requirement I had no desire for X11 on
my build of OpenBSD.
Installing X is the default at install time.
If you choose not to follow the
That's also addressed in the above, but I can give you specifics.
xbase contains two sgid programs, xterm and xlock. xserv contains the
only suid root program, Xorg. If you're super concerned, you can
strip the s bits.
Never strip the s bits from a piece of code.
A lot of s bit software
In the latest snapshots, I've noticed something a little strange. In both
firefox and chrome, every once in a while a line of text will be a
little darker than usual. Like all the gray pixels that make up the smooth
antialiased edges are black. It kind of looks like bold text would look,
but
Do all of our stacks grow down?
Of course not.
what about teduing bpf_timeval from net/bpf.h
Sounds like you don't read commit logs.
bpf_timeval exists so that pcap files can be portable between
machines, and hopefully between systems too.
Unfortunately the upstream tcpdump people did not adopt it
because they have no vision for doing
On Mon, Jul 22, 2013 at 8:00 AM, Kenneth R Westerback
kwesterb...@rogers.com wrote:
On Mon, Jul 22, 2013 at 10:01:25AM +0300, Lars Engblom wrote:
Then I was right regarding how well known the bugs are. ??As you wrote,
there are even known workarounds.
There are steps to diagnose YOUR
x11/nx/opennx
Suggested fix below.
opennx wants to write a timestamp into a configuration file, but
the wxConfigBase framework does not deal with long long. I've
looked a bit into it, but all integer types are mapped to long,
making it problematic to add support for long long. The
I see naddy@ already commited a fix for this from NetBSD. Thank
you!
My patch fwiw was to cast second arg to std::max() to long.
$OpenBSD$
--- src/Toolbar.cc.orig Sat Aug 17 16:58:14 2013
+++ src/Toolbar.ccSat Aug 17 17:08:12 2013
@@ -44,7 +44,7 @@ long nextTimeout(int
So basically, this takes a long long value, and casts it to a long.
Yes, but that's not the entire story.
the function declaration is: long nextTimeout(int resolution)
So it would truncate anyway. But look at it closer. It
takes the value of timeval.tv_sec (your time_t / long
I think most of this is pointless and misleading. The timeout value
that is passed around is NOT a time_t. It's a time offset in the
range 0 .. 3600*1000 milliseconds. Putting it into a time_t is an
abuse of that type.
However, typecasting a time_t to an int is almost always an error.
if we're talking about pushing arc4random patches upstream (which might
be on the cards for various ports with the APIWARN for random() and
friends) I wonder if it might be a good time to consider alternative
(non-cipher-specific) function names, otherwise I suspect we are going
to get
I'm not sure if the stubs/fallback code are necessary, does anyone have
information about the arc4random implementation on other OS behave?
They behave the same.
Except in chroot, where a few of them screw up. And in threads,
where a few of them screw up.
I'm not sure if the stubs/fallback code are necessary, does anyone have
information about the arc4random implementation on other OS behave?
FreeBSD prior to 10.0 does not automatically stir on fork().
This affects all current FreeBSD production releases.
Yes, but for that they are totally
Stuart Henderson st...@openbsd.org wrote:
I'm not sure if the stubs/fallback code are necessary, does anyone have
information about the arc4random implementation on other OS behave?
FreeBSD prior to 10.0 does not automatically stir on fork().
This affects all current FreeBSD
If they don't impliment the arc4random subsystem, they should not be
calling it arc4random.
It's that simple.
Isn't it?
I've never suggested that I was going to send them diffs. The only
thing that is needed, imho, is to point them at their limitations so
that one day the OpenBSD ports tree and third-party projects don't have
to suffer from those.
Look at the log:
revision 1.10
net/isc-dhcp fails to build because of arc4random_addrandom.
Anything calling arc4random_addrandom is insufe. It also is an
API which never should have seen the light of day.
Please don't pull gruesome hacks around time_t problems.
If the code is gross and complex, it is probably because it was
forgotten for a long time. The upstream authors might appreciate
having their attention focused on it.
Make them aware that larger and more varied types for time_t are
coming
On 2013/11/21 15:30, Vladimir Támara Patiño wrote:
Includes patch sent to developer to show position in bigger files,
and changing strcat with strlcat and sprintf with snprintf.
we stopped doing those in ports, they are often intrusive and difficult
to handle at update time, plus there
The hiding of PAGE_SIZE is intentional.
The code should be using getpagesize() or some API which asks the
kernel.
The reason is that PAGE_SIZE is not a standardized symbol, and on some
of our architectures it changes between different processor models.
sysutils/ntfs-3g fails to build on
On Wed, Jan 15, 2014 at 09:31, Antoine Jacoutot wrote:
On Tue, Jan 14, 2014 at 11:06:40PM -0500, Ted Unangst wrote:
I ran pkg_add -u and it printed a warning about @endfake being
obsolete. It may have been in the xvidcore package, or not; it was
hard to tell which package the warning was
On Fri, Mar 07, 2014 at 10:51:50AM +0100, Landry Breuil wrote:
[...]
To everyone experiencing this issue, can you try with this diff:
[...]
Seems to work. I get consistent ~60 FPS with glxgears during
suspend/resume cycles where before I'd get ~60 until the first suspend
and after
Yes. Allthough the inteldrm code wasn't quite as bad in this respect
as the radeondrm code.
No kidding.
My hopethesis about what's causing the problem here is that during the
DVACT_WAKEUP phase, some drivers actually sleep and that userland
processes actually get to run.
Yes, that is my
DVACT_WAKEUP does finish its job. It's just that it is doing so while
kernel threads and userland processes are running as well. Drivers
need to be aware of this, and I'm not sure they all are.
Well the only thing which could stop that X process from playing with
stuff, is the driver it
I don't see the point.
1) Collisions happen in other places.
2) Noone who runs into this will have read the note before they run
into the situation.
Is this worth committing?
Thanks
Index: current.html
===
RCS file:
1 - 100 of 462 matches
Mail list logo
