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?
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
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 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
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
What architectures are getting packages for the 4.6 release?
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?
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
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
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
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
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
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 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
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
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
.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.
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
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.
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
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
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
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
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
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 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
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
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,
* 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
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
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
...
+---
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
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.
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.
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
- 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).
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?
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 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,
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 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')
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
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
401 - 462 of 462 matches
Mail list logo