Okay, the question is: why 4 ? why not 3 ? or 2 ? or 8 ?
Where do you stop ? how did you figure out that 4 was better ?
This looks a bit like hey, let's make our own crypto code, it ought to
work just fine, right ?
Sorry, badly phrased reply. I didn't mean to imply it was a bad idea, but
you didn't explain at all why 4, and not 3 or 6, or 42 ? If it's good with
4, it ought to be better with more, right ? any data point or rationale for
choosing 4 ?
On Sat, May 03, 2014 at 11:28:16AM +0200, Reyk Floeter wrote:
On Fri, May 02, 2014 at 06:50:04PM -0600, Bob Beck wrote:
What's their hangup with %n? We normally don't like polluting the world
with #ifdef OPENSSL_NO_PERCENT_N... We normally nuke stuff like that
Well, it is an evil thing
On Sat, May 03, 2014 at 01:00:28PM +0200, Henning Brauer wrote:
* Marc Espie es...@nerim.net [2014-05-03 11:50]:
On Sat, May 03, 2014 at 11:28:16AM +0200, Reyk Floeter wrote:
On Fri, May 02, 2014 at 06:50:04PM -0600, Bob Beck wrote:
What's their hangup with %n? We normally don't like
On Sun, May 04, 2014 at 12:21:04AM -0700, patrick keshishian wrote:
why not use calloc(2)?
Because it doesn't exist ?
(hint: the 2 in calloc(2) is the manual section. There is no calloc system
call, therefore you can't be right. See guenther(2) for a more serious answer).
On Thu, May 08, 2014 at 12:07:30PM +0200, Stefan Sperling wrote:
On Wed, May 07, 2014 at 07:44:51PM +0200, Ingo Schwarze wrote:
While LC_CTYPE and LC_COLLATE make some sense, LC_MONETARY, LC_NUMERIC,
and LC_TIME are badly overengineered, pointless bloat, causing nothing
but surprising,
I already sent a preliminary version of this patch to selected people.
Now that packages use long names when needed, we can pinpoint every file
in the archive based on its archived name.
This patch changes pkg_add to be able to extract archives that contain
elements out-of-order, e.g., match
Tweaked version. The previous version was working just fine, but this
one also marks hardlinks and symlinks as skippable, as should be.
It also adjusts the pace of progress slightly (making the meter jump AFTER
skipping the entry), and also it does prepare_to_extract systematically
(which will
I've just switched on out-of-order packages, after much testing.
What this means:
new packages won't be compatible with older pkg_add. Most specifically,
the plist order may no longer match the packing-list.
- if you see strange pkg_add errors, and your base system is not uptodate,
that's your
On Fri, Jul 11, 2014 at 10:27:57AM -0400, Ted Unangst wrote:
On Fri, Jul 11, 2014 at 14:09, Florian Obser wrote:
usr.sbin, make sure subdirs of subdirs see usr.sbin/Makefile.inc:
Does the same thing as lpr/pac and pppd/pppstats. I have no idea if
this is the right way, but it seems to
On Fri, Jul 11, 2014 at 04:55:36PM +, Doug Hogan wrote:
Index: usr.bin/m4/eval.c
===
RCS file: /cvs/src/usr.bin/m4/eval.c,v
retrieving revision 1.72
diff -u -p -d -r1.72 eval.c
--- usr.bin/m4/eval.c 28 Apr 2014 12:34:11
On Fri, Jul 11, 2014 at 11:07:10PM +, Miod Vallat wrote:
it. As expected, OPENSSL does the opposite and makes life harder for
everyone.
Hasn't this been the OpenSSL roadmap since the very beginning?
Jury is still out as whether they did it on purpose, or whether it was
just a
I've just committed changes to pkg_create that will help mirrors
synch by using much less bandwidth.
I just ran a final test. Rsynching a full amd64 snapshot now says something
like:
sent 7,315,796,510 bytes received 40,292,721 bytes 4,517,095.01 bytes/sec
total size is 28,752,806,019 speedup
On Mon, Sep 22, 2014 at 09:42:58AM +0200, Marc Espie wrote:
I've just committed changes to pkg_create that will help mirrors
synch by using much less bandwidth.
I just ran a final test. Rsynching a full amd64 snapshot now says something
like:
sent 7,315,796,510 bytes received 40,292,721
On Sun, Oct 19, 2014 at 09:25:51AM +0200, Matthieu Herrb wrote:
On Thu, Oct 16, 2014 at 08:14:16PM +0200, Mark Kettenis wrote:
Hi Marc,
Is there a reason why conditional includes (sinclude/-include) aren't
enabled in OpenBSD?
I'm asking because the Xorg people now use it in one of
On Wed, Jun 19, 2013 at 01:40:19PM +0200, Martin Pelikan wrote:
If you're right that atomic_{clear,set}bits_int is correct and
sufficient and actually faster, then all dynamic executables would
benefit from this speedup (sigprocmask is used in ld.so(1)).
Since on i386 GENERIC these
On Fri, Jun 21, 2013 at 11:03:16AM +0200, Mark Kettenis wrote:
Date: Fri, 21 Jun 2013 10:50:42 +0200
From: Landry Breuil lan...@rhaalovely.net
On Fri, Jun 21, 2013 at 10:20:01AM +0200, Mark Kettenis wrote:
Well, lots of ports stuff is compiled with newer gcc versions anyway.
On Sat, Jun 22, 2013 at 12:06:51PM -0700, Ryan Freeman wrote:
On Sat, Jun 22, 2013 at 07:00:09PM +0200, Max Power wrote:
Hi guys!
OpenBSD 5.3/amd64:
pkg_add apache-httpd [ok.]
next step
/etc/rc.d/httpd2 start
returns:
httpd2(failed)
Instead
/usr/local/sbin/apachectl2
On Mon, Jul 08, 2013 at 11:36:14PM -0700, Matthew Dempsky wrote:
Might be nice to mention that 5.4 'was' the first release that used
ELF on all platforms?
Starting
.Ox 5.4 ,
all supported platforms use it as the native binary file format.
On Mon, Jul 8, 2013 at 11:16 PM, Simon Kuhnle
On Tue, Jul 09, 2013 at 06:09:02PM +0200, Simon Kuhnle wrote:
On Tue, Jul 09, 2013 at 12:29:10AM -0700, Matthew Dempsky wrote:
On Tue, Jul 9, 2013 at 12:22 AM, Marc Espie es...@nerim.net wrote:
Starting
.Ox 5.4 ,
all supported platforms use it as the native binary file format.
I
On Sat, Jul 20, 2013 at 12:40:47AM +0200, Alexander Bluhm wrote:
Hi,
Enable gcc warnings for arp, rarpd, ndp and fix findings.
ok?
bluhm
Index: usr.sbin/arp/Makefile
===
RCS file:
On Tue, Aug 06, 2013 at 12:37:49AM +0200, Mark Kettenis wrote:
The atomic_setbits_int() and atomic_clearbits_int() implementations
use stwcx., which touches the condition code register. This means we
need to tell GCC that it gets clobbered. Fixes issues with
uvm_page_physload() which
On Wed, Sep 11, 2013 at 05:36:45PM +0300, Valentin Zagura wrote:
Thanks for the suggestion, we will probably order the CD.
But on the other hand, I hope that you realize that people in some
countries (Iran, China, Egypt, Syria) would not have this possibility and
they could be more affected
In general, when we don't have enough of a device, we end up with clonable
shit or something don't we ?
On Fri, Sep 13, 2013 at 07:24:27PM +0200, Mark Kettenis wrote:
Date: Fri, 13 Sep 2013 17:55:17 +0200
From: Marc Espie es...@nerim.net
In general, when we don't have enough of a device, we end up with clonable
shit or something don't we ?
Not really. Cloneable devices are used
On Mon, Sep 16, 2013 at 08:57:11PM +0200, Antoine Jacoutot wrote:
Any other thoughts?
Is there any way we could use something else than file(1) ?
Well, you can look for a script using dd and matching it against
the two possible signatures. e.g.,
dd 2/dev/null if=file bs=4 count=1|grep -qe
On Mon, Sep 16, 2013 at 11:28:06PM +0200, Alexander Hall wrote:
sed can do it all. Really. Notes:
- I separate re_quote() cause I think it can be useful in other places.
- I think re_quote() is (basic) regex complete.
- I don't care if the interpreter is (or seems) nonexistant, as that
On Thu, Sep 12, 2013 at 02:35:02PM -0400, James Turner wrote:
Attached is a diff to update our in tree version of SQLite to the
recently released 3.8.0.2. SQLite 3.8.0 is needed for a fossil update
I'm working on.
I've tested this diff against my fossil update and everything appears to
be
be sure to not have any old sessions hanging around
before you rebuild source, as you will be unable
to reattach these.
(quick fix: recompile tmux from -D2013-09-01,
don't install the binary, but use it to attach
to your old session. Just saved my ass).
The following patch expands config(8) slightly to be able to say
make reconfig from the build directory.
Yeah, it's sugar, but it got tiresome having to change directories
all the time.
I've put the reconfig target at end, where I'm sure it can't be the
first target.
An alternative approach
Theo says no need for reconfig, make config will do just fine.
okays ?
Index: config.h
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/config/config.h,v
retrieving revision 1.25
diff -u -p -r1.25 config.h
--- config.h5 Dec
Backforth with Theo. A bit more logic.
Most trees are moveable, and it's possible to
do so when -b is not in use...
Index: config.h
===
RCS file: /build/data/openbsd/cvs/src/usr.sbin/config/config.h,v
retrieving revision 1.25
diff -u
On Fri, Nov 01, 2013 at 04:56:04PM +0100, Ingo Schwarze wrote:
Oh well. To paraphase (forgive me if i misunderstand), It ought to
be easy to write something better than Module::Build, and even though
nobody has so far volunteered to propose an actual design, and even
less to write some code,
On Tue, Nov 19, 2013 at 12:11:17AM -0500, Ted Unangst wrote:
On Mon, Nov 18, 2013 at 18:49, Philip Guenther wrote:
btw, no library version change because the function stubs already
existed.
Hmm, since this is actually offering new functionality (by sem_open()
and friends no longer
On Tue, Nov 26, 2013 at 02:38:43PM +, Stuart Henderson wrote:
Is this OK, or should we remove bits about building packages
individually too?
I'd rather send people to ports(7) directly... since that explains both
single port and bulk building.
Index: share/man/man8/release.8
On Tue, Nov 26, 2013 at 03:38:49PM +, Stuart Henderson wrote:
On 2013/11/26 16:28, Marc Espie wrote:
On Tue, Nov 26, 2013 at 02:38:43PM +, Stuart Henderson wrote:
Is this OK, or should we remove bits about building packages
individually too?
I'd rather send people to ports(7
On Sat, Nov 30, 2013 at 12:59:54PM +0200, Lars Nooden wrote:
perlre(1) seems to be missing information about substitution evaluations
with the /e option. The functionality is present in perl:
perl -e '$_=2; s/2/1+3/e; print'
But it is not listed in the base documentation. The
On Tue, Dec 10, 2013 at 10:31:31PM +0100, Mark Kettenis wrote:
Date: Tue, 10 Dec 2013 21:48:41 +0100
From: Christian Weisgerber na...@mips.inka.de
New attempt, now that the userland has been cleaned up. This diff
kills the remaining parts of the COMPAT_43 tty handling in the
kernel.
On Tue, Dec 10, 2013 at 11:05:01PM +0100, Marc Espie wrote:
Note that tcgetsid(3) is part of posix 2008... I don't see this as
a noxious interface, so I don't see any reason not to keep it...
My bad, it's XSI in posix 2008, but I was reading posix 2013, which has:
Issue 7
The tcgetsid
I'm thinking I'd like to impose a PATH for running @exec/@unexec
style lines in packing-lists.
Some people have their default path ignoring /usr/local, which is just
fine, but the packages expect things to run in a correct way, so currently
any local command requires /usr/local/bin/cmd to be run
@@
#! /usr/bin/perl
# ex:ts=8 sw=4:
-# $OpenBSD: PkgAdd.pm,v 1.41 2013/12/31 11:24:55 espie Exp $
+# $OpenBSD: PkgAdd.pm,v 1.40 2013/12/25 14:38:15 espie Exp $
#
# Copyright (c) 2003-2010 Marc Espie es...@openbsd.org
#
@@ -134,15 +134,11 @@ sub handle_options
$state-{do_faked} = 1
Something like this for the program itself:
Index: signify.c
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/signify/signify.c,v
retrieving revision 1.5
diff -u -p -r1.5 signify.c
--- signify.c 31 Dec 2013 17:33:17 - 1.5
On Wed, Jan 01, 2014 at 12:53:09PM -0500, Ted Unangst wrote:
On Wed, Jan 01, 2014 at 16:25, Marc Espie wrote:
Now that you're fixing it, I think you've still got it wrong.
Instead of
signify -V -p pubkey -i input
you want to be able to do
signify -V -p pubkey input ...
e.g
Revisiting the error messages:
- pass the filenames to the low-level functions, so they can tell you
what's going on.
- FIX readall and writeall. The logic *is* wrong. Just because they
return something != len, doesn't mean they return -1.
Okay ?
Index: signify.c
On Thu, Jan 02, 2014 at 10:36:53AM -0500, Ted Unangst wrote:
On Thu, Jan 02, 2014 at 14:40, Marc Espie wrote:
Revisiting the error messages:
- pass the filenames to the low-level functions, so they can tell you
what's going on.
- FIX readall and writeall. The logic *is* wrong. Just
I really, really want to have an actual parameter for sign and verify,
this makes more sense.
Also, the set of modes of signify means it's much clearer to have separate
synopsis in the manpage...
Also fix some .Ar which should be .Fl while we're at it.
To *keep things simple*, let's only sign a
Rechecked that -G was working (broken) and jmc wants identical SYNOPSIS/usage.
Together with the \n for base64...
Index: signify.1
===
RCS file: /build/data/openbsd/cvs/src/usr.bin/signify/signify.1,v
retrieving revision 1.6
diff -u
On Fri, Jan 03, 2014 at 10:46:45AM -0500, Ted Unangst wrote:
On Fri, Jan 03, 2014 at 16:39, Marc Espie wrote:
Rechecked that -G was working (broken) and jmc wants identical
SYNOPSIS/usage.
Together with the \n for base64...
+ } else if (verb == NONE) {
usage();
this is weird
Looking more closely at the generated files, they don't have terminating
newlines...
The base64 routines will properly ignore newlines, since they match isspace().
okay ?
Index: signify.c
===
RCS file:
The following patch removes pure package additions in pkg_add:
instead of having separate code paths for normal installs and for updates
(with extract then install), everything follows the extract then install road.
There are several reasons behind this patch:
first, it simplifies the code, and
On Tue, Jan 07, 2014 at 04:54:59PM +, Christian Weisgerber wrote:
(I'm also open to reconsidering whether keys should include
identifiers. Perhaps a random id created during key generation? Just
enough to say you're using the wrong key.)
I'm in favor.
Yeah, looks like a good idea.
64
On Tue, Jan 07, 2014 at 01:17:12PM -0500, Ted Unangst wrote:
On Tue, Jan 07, 2014 at 16:54, Christian Weisgerber wrote:
Ted Unangst t...@tedunangst.com wrote:
To that end, I think the comment should be marked as untrusted, and
signify should even check that it says untrusted. Hopefully
On Wed, Jan 08, 2014 at 03:53:32PM -0500, Ted Unangst wrote:
This may or may not be useful. We can embed the message after the
signature and reduce the number of files in half. It's not a lot of
code. (This is how the crypto_sign API originally worked, but we've
since added some metadata, so
We're currently trying out some new stuff, purely as an experiment (the
files in /etc/signify all say so explicitly, don't put any confidence in
them)
if you experience trouble running fw_update, make sure you have
a new snapshot.
if you're trying to use pkg_add directly to grab/update
On Fri, Jan 10, 2014 at 08:05:44AM +0001, Jason McIntyre wrote:
On Fri, Jan 10, 2014 at 01:01:46AM -0700, Theo de Raadt wrote:
well then this means the description of -c is very poor. i would look
for a fix there, not in SYNOPSIS.
But look closer, the synopsis is wrong:
It's probably time to talk about it.
Yes, we are now distributing signed packages. A lot of people have probably
noticed because there was a key mismatch on at least one batch of signed
packages.
Obviously, we haven't finished testing yet.
Don't read too much into that. Signed packages just
On Fri, Jan 17, 2014 at 09:59:03AM +0100, Sébastien Marie wrote:
On Thu, Jan 16, 2014 at 10:02:22AM +, Stuart Henderson wrote:
On 2014/01/16 08:53, Sébastien Marie wrote:
Hi,
Does it make sens to have an option to require package to be signed ?
It makes more sense to just
On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote:
Awesome.
 * the public one on the client openBSD
 * the private one on the builder
is there a new make command in ports to sign ? like make sign ? make
resign ?
See signify(1), pkg_add(1), pkg_create(1),
On Fri, Jan 17, 2014 at 06:23:53PM +0100, Marc Espie wrote:
On Fri, Jan 17, 2014 at 12:09:31PM -0500, sven falempin wrote:
Awesome.
 * the public one on the client openBSD
 * the private one on the builder
is there a new make command in ports to sign ? like make sign
On Fri, Jan 17, 2014 at 12:39:49PM -0500, sven falempin wrote:
i read the manuals , and well , i am still unsure,
if i put SIGNER=bob in the package configuration
then it will be signed with
/etc/signify/bob.sec
having to read 4 different manual page to get this is strange :p
No,
On Wed, Jan 22, 2014 at 01:46:33PM +0400, Loganaden Velvindron wrote:
The signing framework in pkg_add/pkg_create is much older than that, if
was written for x509 a few years ago, but signify(1) will probably be more
robust and ways simpler. In particular, there's no chain-of-trust, so
A huge swath of clean-up has just hit the trees.
Most specifically, now that it works, the signing-only code has been
moved into a separate pkg_sign command.
This is partly for documentation purpose: it's much simpler to document
the parameters to that command separately, instead of as additions
You should realize that the pkg tools have gone thru *major internal changes*
over the last month or so.
If you see weird things happening, now is a really good time to report them,
before it's too late...
Also, the 5.4 - 5.5 update is going to be fun: there was a kernel flag day.
The proper
On Fri, Jan 24, 2014 at 11:15:21PM -0600, Shawn K. Quinn wrote:
On Fri, Jan 24, 2014, at 06:50 AM, Marc Espie wrote:
You should realize that the pkg tools have gone thru *major internal
changes*
over the last month or so.
If you see weird things happening, now is a really good time
On Fri, Jan 24, 2014 at 08:08:29PM -0500, Ted Unangst wrote:
I generally associate negative connotations with so-called, as in
the so-called free world. I wouldn't use it just to name something,
as in the kernel is written in the so-called C language. so-called
implies it's called this, but
On Sat, Jan 25, 2014 at 11:04:21PM -0600, Shawn K. Quinn wrote:
On Sat, Jan 25, 2014, at 08:53 AM, Marc Espie wrote:
I agree with so-called having negative connotations.
I think both those instances are using it intentionally, namely there
are nasty surprises in some MBR blocks
hopefully, things should be back to normal.
last commit was
revision 1.37 of PackageLocation.pm
date: 2014/02/09 11:13:59; author: espie; state: Exp; lines: +4 -3;
do a better job in wipe_info: close files and reap children.
also wipe every state variable... fixes reget update_info in fringe
On Sun, Feb 09, 2014 at 01:16:38PM +0100, Marc Espie wrote:
hopefully, things should be back to normal.
last commit was
revision 1.37 of PackageLocation.pm
date: 2014/02/09 11:13:59; author: espie; state: Exp; lines: +4 -3;
do a better job in wipe_info: close files and reap children
On Sun, Feb 09, 2014 at 01:16:38PM +0100, Marc Espie wrote:
hopefully, things should be back to normal.
last commit was
revision 1.37 of PackageLocation.pm
date: 2014/02/09 11:13:59; author: espie; state: Exp; lines: +4 -3;
do a better job in wipe_info: close files and reap children
On Wed, Feb 12, 2014 at 08:16:26AM +0100, Mark Kettenis wrote:
Just make sure you set $ARCH in your .profile.
If you feel like it, how about a patch for /etc/skel ?
It's not set by default !
On Sun, Feb 16, 2014 at 03:11:07PM +0100, Ingo Schwarze wrote:
Few, probably, because mandoc(1) is fast enough that we run in on
demand whenever possible and usually avoid preformatting anything
during builds, or where we do preformat, we use groff for that, anyway.
But even missing one single
On Tue, Feb 18, 2014 at 02:50:53PM -0700, Todd C. Miller wrote:
On Tue, 18 Feb 2014 16:38:07 -0500, Ted Unangst wrote:
True, I phrased that poorly. What I'm assuming is that the code will
be built by a compiler that supports the const keyword. Or in other
words, if you're using a 25 year
On Thu, Mar 06, 2014 at 03:18:38PM +, Devin Ceartas wrote:
Are all the ports in the packages in snapshots? I seem to remember needing to
build some of the things I use to test, but maybe that has changed.
There are a few ports not in snapshots, stuff that is not authorized for
ftp
-current work, again.
Doing chroot on distant hosts involves chroot, obviously... This doesn't
work too well with sudo (the processes tends to be hard to kill, so if
you've got to interrupt dpb, ouch).
There are no exact instructions for using dpb in chroot settings.
Obviously, you need a
kili@ just committed a revert of the librt addition in src and corresponding
patches in ports.
If you've built a tree with librt, you want to
# rm -f /usr/lib/librt.a
This lib was added to facilitate porting software, as posix asks for it.
but since it's only a stub, it was only added as a
On Sun, Mar 23, 2014 at 10:46:08PM +0400, Loganaden Velvindron wrote:
On Sun, Mar 23, 2014 at 10:34 PM, Marc Espie es...@nerim.net wrote:
kili@ just committed a revert of the librt addition in src and
corresponding
patches in ports.
If you've built a tree with librt, you want
On Sun, Mar 23, 2014 at 05:05:06PM -0400, STeve Andre' wrote:
On 03/23/14 14:34, Marc Espie wrote:
kili@ just committed a revert of the librt addition in src and corresponding
patches in ports.
If you've built a tree with librt, you want to
# rm -f /usr/lib/librt.a
Shouldn't
I found out, after a bit of head-scratching, that you will have to
make sure you're running the newly compiled mountd if you want cred-mapping
to make sense.
e.g., the usual build kernel, reboot, make build is not enough. You
also have to kill mountd and start the new one, otherwise
Got fed up of the nth report flavors are broken.
The cause is always the same: for packages to build correctly, your setup
*must* propagate some env variables thru sudo during the fake/packaging stage.
So, I finally added up a variable that's there just to trigger an error in
case your setup is
On Wed, Apr 16, 2014 at 08:07:55PM +0400, Vadim Zhukov wrote:
This is a PoC I'm currently using while hacking at our libtool. What
I dream about is putting such code in /usr/share/bsd.perl.mk or such,
allowing to run checks for all Perl-based tools in base.It's better to
know something is
On Thu, Apr 17, 2014 at 12:22:44PM -0500, Adam Thompson wrote:
Given the single-threaded nature of much of the kernel, what applications do
you run where multiple CPUs makes much of a difference to OpenBSD?
You're a narrow-minded troll.
On Fri, Apr 18, 2014 at 09:41:47PM -0400, Jacob L. Leifman wrote:
I'm guessing that openssl was incorporated into OpenBSD base without
prior sufficient audit by the OBSD devs because it was presumed to have
better auditing / quality control upstream given its security critical
nature and
Since the tree wants to move fast, here's a sketch of how we deal
with ports breakage.
- someone makes sure everyone is aware there's breakage. ports and src
should communicate so we assert what got removed intentionally, what
got removed by accident.
- if the removal is not accidental, fix
At least jeremy@ and landry@ got confused about this, so I expect more people
to ask.
The algorithms for package updates are a bit complicated, to say the least.
When you update a package with shared libraries, those can get split off
into a separate package with a .lib name (which is well
On Sat, Apr 02, 2011 at 01:45:36PM -0500, Amit Kulkarni wrote:
Hi,
I am replying in a single email.
I do a fsck once in a while, not regular. In the last 6-8 months I
might have done it about 5 times. And I did it multi-user the few
times I did it, but plan on doing it single user in
On Sun, Apr 10, 2011 at 11:27:41AM +, Miod Vallat wrote:
Now, consider this: the fs code is very heavily tested. People use it 24
hours
a day, 365 days a year.
Except on leap years, of course. Those years see even more real-life
testing happening!
Good point. Maybe we should go to
On Sun, Apr 10, 2011 at 02:40:09PM +0200, David Vasek wrote:
On Sun, 10 Apr 2011, Marc Espie wrote:
This is completely stupid.
What do you trust more ? your file system, or fsck ?
oth have bugs ! I'm sure of it !
so, if you run fsck, it's likely
you're going to run into fsck bugs
Like most people, I have my pet peeves. I consider that documentation
is very important to code quality.
I ran into a school-book example a week ago, so I decided to share what I
mean.
There was this problem with dpb where some packages in a MULTI_PACKAGES show
up as Errors when they don't
I'm happy with this as well.
I think the libstdc++ is a good way to track i18n progress. When we implement
enough of it, more code will activate.
Even if we don't use it much directly wfscanf would be nice.
My guess is that having both wfprintf and wfscanf will lead to working wide
streams,
On Fri, May 27, 2011 at 07:01:28AM +, Jacob Meuser wrote:
can we please just accept that a 100% perfect for everyone solution
is not really possible?
Of course not, that way lies mediocrity. ;-)
On Sat, Jun 11, 2011 at 09:06:05PM +0200, gilbert.fernan...@orange.fr wrote:
One knob to be able to turn it on so when you're working
on a machine, and console dies, to be able to shutdown
properly and avoid a fsck.
One knob for the dwarfen guys that work in the IT mines, to bind the machines
If we start adding this to some tools, it would start to make sense to
support it at the source.
Namely, conversion functions are a bit annoying, and it's always possible
to fuck it up. Plus, same code twice = same bugs.
Is there anything preventing us from adding non-standard flags to
INSTALL and DEINSTALL were deprecated in June 2007, and removed from
pkg_create in January 2010.
I think it's time to remove all traces of +MTREE_DIRS, +REQ, +INSTALL,
+DEINSTALL
from all commands.
Index: pkg_add.1
===
RCS file:
===
RCS file: pkg_merge
diff -N pkg_merge
--- pkg_merge 28 Jul 2010 12:19:54 - 1.21
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,257 +0,0 @@
-#! /usr/bin/perl
-# Copyright (c) 2005-2007 Marc Espie es...@openbsd.org
-# $OpenBSD
On Wed, Aug 24, 2011 at 07:22:47PM +0200, Landry Breuil wrote:
On Wed, Aug 24, 2011 at 12:39:07PM +0200, Marc Espie wrote:
Apparently, nobody cares about fat packages.
Not surprisingly, killing that code simplifies a few things.
Especially since the necessity of passing arch around
On Wed, Sep 07, 2011 at 12:26:30PM +0200, Marian Hettwer wrote:
Hi there,
see attached diff to PackageLocator.pm.
It seems like in it's current version it doesn't support multiple
installpath entries, like:
installpath = ftp://mymirror/localrepo
installpath += ftp://mymirror/officialrepo
I promised yesterday I was going to write an email explaining what this
is about.
This has got everything to do with reproducible package builds, and the
complexity that's package version numbers.
First, here's the situation before the change
-
Take
On Wed, Oct 05, 2011 at 12:05:18AM +0100, Nicholas Marriott wrote:
And from the look of it they also have -J, but .xz is so rarely used
right now I'm not sure it is something we really need to copy...
That's not gonna be the case from gnome3 (for instance). As I've been
told by Antoine, they're
On Thu, Oct 06, 2011 at 04:00:21PM +0100, Nicholas Marriott wrote:
I can't really follow what it is trying to do. Won't your change always
call infocmp if TERMCAP is not set instead of searching through the
files?
It looks like currently infocmp is only used if there are no termcap
files at
On Thu, Oct 06, 2011 at 05:04:03PM -0700, patrick keshishian wrote:
yuck... sounds like linux to me. please don't go down that route of
enable everything, it can't hurt even if you don't use it mentality.
In a wide difference to linux, we try to avoid running buggy shit on the
system by
1 - 100 of 615 matches
Mail list logo
